>I think the QLinux addition are very useful for realtime-multimedia content,
>but actually Linux has some limitations regarding locking,
>which makes impossible for example to play real-time generated audio with
>20ms latency.
>
>So unfortunately Linux + QLinux additions can not be called media-OS.
Although I think that the idea of explicitly treating the audio data
stream as completely independent of disk IO has a great deal of merit,
particularly since it corresponds precisely to physical reality, I
feel a need to clarify Benno's remarks about what Linux can and cannot
do.
It is *not* true that Linux can't play real-time generated audio with
20ms latency. My program Quasimodo plays real-time generated audio
with 1.3ms latency (and sometimes less), and that is *without* the use
of RT scheduling. I don't get audio dropouts ever when its the only
active process besides X, and sometimes I can even compile stuff with
it running and get no audio dropouts.
It *is* true that if there is a lot of disk activity, particularly
with IDE disks but also to a lesser extent with SCSI, then latencies
below about 100ms lead to audio dropouts.
Its also true that Windows can do 20ms latencies *with* heavy disk
activity, but it can't do 1.3ms latency under any circumstances. So
right now, we have to pay (or not pay) our money and take our choices.
Still, it would be nice, as I said above, for writes to audio devices (and
MIDI, and serial, and all other non-disk devices) to be considered
independent of any locking or synchronization schemes used for disk
writes. There is no reason that I can see for their to be any
relationship between write ("/dev/sda1", ...) and write ("/dev/dsp",
...), certainly not once any lookups the file descriptors are done.
--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/