Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

>Given all that, if you want to take a Linux box and use it to drive a
>pile of devices with hard guarentees (think factory floor, CNC devices,
>mixers, lots of stuff that is currently done in ASICs), then you need a
>better answer than Linux gives, even with the Ingo patches.  

I couldn't agree more. But please don't confuse that problem space
with the one in which real-time audio operates. 

>Seems like we are close to having a decent answer, why not support it
>for those applications?

We should. For *those* applications. I honestly, and without any
perverse intent, don't consider them in the same problem space. 

	 1) nobody gets hurt if there is an audio dropout
	 2) typical control programs don't do streaming disk i/o,
	       don't use lots of memory, and don't operate on a
	       continuing, periodic basis.

I wrote the device driver and control program for the largest
automated film sorter in the US about 10 years ago (8 motors, about 24
IR sensors, 5 air-activated gates, etc., etc.)  It ran under SCO, and
it worked 100% (when the hardware did, anyway). Ah, those 33MHz 386's:
the things you could do :)

But thats a totally different design space than the high-end audio
stuff I work on these days. Nobody in the right minds would have
dreamt of doing that driver in user space (or in linux-space under
RTLinux), just as nobody would seriously want to put a soft-synth into
a device driver or RTLinux process. 

(in what follows, assume that interrupts are serviced in a timely
fashion, so that whatever support a driver provides is always carried
out on time)

The biggest difference: for automated systems, if there is a delay in
the response of the control program to a new device state then its not
automatically the case that a serious error will occur.

In the audio world, the opposite is true: if the user space component
of a soft-synth or FX processor hasn't generated its samples in time,
the default action of the device driver/RTLinux process, whatever that
action is, will always "be wrong". Not sometimes, *always*.

Luckily, no film cassettes nor people will be injured as a result :)

--p