Messages in this thread | | | Date | Fri, 23 Jul 1999 06:18:49 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Paul Barton-Davis wrote: (...) > What they require is guaranteed maximum *jitter*. This is where the > problem comes in. I don't believe that RTLinux is the required answer > here.
No, not really. Quite a bit more than some 20 us jitter would be acceptable...
> These applications are not hard real time in the sense that > RTLinux has been written to support.
...but HARD real time is still an absolute requirement.
> All they ask is that the > operating system never deny them resources if they want to use them > and such use doesn't interfere with or require the cooperation of any > other subsystem and/or process. That means "CPU hungry", not > "absolutely constrained by timing issues".
I'd say both. In order to be usable for professional audio (live in particular), these applications NEED to meet EVERY deadline. If there can be occational drop-outs when doing reasonably low latency processing, I'm going elsewhere.
Until now, dedicated DSP hardware has been the way of doing what Audiality will do. Without hard real time, that won't change. The whole idea with this hard real time engine is to enable low latency processing without external hardware. It's NOT the average audio API, or whatever... That part still belongs in soft real time user space.
> Linux doesn't do this right now. If someone else is using a "key" > piece of the kernel, then nobody else may proceed in spite of the fact > that proceeding would not utilize or corrupt any of the resources used > by the current lock holder. That is, lock granularity is not only too > large, but crosses distinct protection domains which should be > independent.
Yep, I know, and fixing that might be enough. However, is that enough to guarantee that a real time task will get control within any defined time? I want figures. Hard, real, reliable figures.
> The "simple" change of explicitly recognizing the existence of > distinct I/O subsystems would provide almost everything that a "low > latency (audio)" application requires; it might even provide it > all. Allowing I/O via hardware unrelated to the disk subsystem to > proceed unhindered by disk I/O is good sense for all kinds of reasons, > and would move Linux into the BeOS arena in one step.
That would be very nice indeed! :-)
> KURT would be nice for audio (and possibly MIDI) sequencing, but not > necessary for the above solution to offer all of its own > benefits. What exactly are Linus' objections to the KURT patches ?
I suspect there are similarities between some of Linus' objections and mine...
Anyway, the main reason why I haven't even tried KURT yet (guess I should) is the normal/RT mode idea. IMHO, no application should EVER shut some parts of the system out. If there's free CPU time and work to be done, get to it! Unless every part of the OS is completely functional even when some tasks require hard real time scheduling, the system is crippled. Not the way to go. Again, just MHO... (I might be missinformed regarding the latest developments around KURT.)
> Aureality sounds interesting, but as est observed, unlikely to offer > an environment conducive to interesting audio application > development. SCHED_FIFO+I/O subsystems seems like a much more > interesting approach to me.
What is an audio application?
This is what I have in mind anyway:
Your soft/firm real time application stays in user space, and use the Audiality Client Application Interface, much like it would use OSS or ALSA. (There will be compatible interfaces as well.) The big difference is that it may use plug-ins running under the low latency engine as if they were running on a dedicated DSP. You may still do "high latency" processing in the application just as it's done now.
I intend to make it possible to run Audiality plug-ins in user space as well, as that's the simplest and most efficient way to do off-line, non real time processing. And it also means you can just steal the user space plug-in host and use the plug-ins, if you really can't stand the hard real time engine. ;-)
//David
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |