Messages in this thread |  | | | Subject | Re: [alsa-devel] Re: real-time threaded IO with low latency (audio) | | Date | Thu, 22 Jul 1999 22:47:08 -0400 | | From | Paul Barton-Davis <> |
| |
>Yes, I've seen the KURT site, but not looked much closer at it.
You should :)
>Perhaps I should have mentioned Firm Real Time as a third kind. (It's >more or less what I sugested for multimedia later on in the original >post. However, I really don't like the normal mode/real time mode >switching idea...) But as I was more focused on the issue that makes all >the difference to some applications; guaranteed maximum latency;
To rehash a point made on alsa-devel recently:
Realtime software synths and FX processors don't require low latency, although its certainly useful. Linux (like most other reasonable operating systems) doesn't get in the way of low latency. You can set the fragment size as low as the soundcard h/w will allow, and you'll get the latency you asked for.
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. These applications are not hard real time in the sense that RTLinux has been written to support. 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".
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.
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.
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 ?
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.
--p
- 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/
|  |