Messages in this thread | | | Subject | Re: [alsa-devel] Re: lantency scheduling benchmarks of audio playing tasks during high disk I/O | Date | Mon, 21 Jun 1999 11:44:15 -0400 | From | Paul Barton-Davis <> |
| |
Benno writes:
>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/
| |