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/