>There are two different problem spaces:
>1. Live -- which seems to me to be a hard realtime application when you
> talk about serious quality.
> Time_data_in - Time_data_out < K
I ask you again, just as I asked Larry: if K was 10 seconds, would
anyone characterize this as "hard realtime" ?
Nothing is gained by trying to classify this behaviour as <some
words>. Lets just talk about actual worst case latencies, and then we
can establish if there is or is not a way to satisfy the live (aka
"real time" for audio folk) situation with a "standard kernel". if it
really can't be done (and Benno's tests of Ingo's patches suggests it
can), then some RT-enabled linux is clearly the way.
The actual times, as I mentioned are:
for MIDI data in -> audio data out: ideally, about 1ms, which is
the wire transmission time
for a single MIDI NoteOn message
for audio data in -> FX -> audio data out: no more than 3 ms,
since any more will cause
"comb filtering" when the
output signal is combined
with the original audio (externally,
of course, but this is a
common situation).
>2. Places where some serious buffering (ok, not seconds, perhaps) is ok.
> I thought we were discussing this -- and people here have been saying
> that there is a great deal of applications in this space.
Yes, and none of them need any real-time patches or anything else.
To do multichannel disk playback with a file-per-channel approach
(totally desirable), right now you need to buffer 2-5 seconds of audio
per channel to cover disk i/o jitter, but this is an entirely
different problem area, since its induced by physical seek time much
more than the kernel. It is a tricky problem to solve correctly, but
is more or less totally unrelated to latency issues. That is, even
with a zero-latency kernel, whatever design is needed to handle this
is still needed. Worse latency characteristics just look like a really
sucky disk controller.
--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/