Messages in this thread | | | Subject | Re: lantency scheduling benchmarks of audio playing tasks during high disk I/O | Date | Mon, 21 Jun 1999 14:14:21 -0400 | From | Paul Barton-Davis <> |
| |
>Using very small buffers (<5ms) , it's hard to actually HEAR these drop-outs, >if you get only sporadic drop-out, let's say every 5-10 sec. >But, they are present. >The best way I found to measure these deadlines is to use the >Pentium RDTSC cycle counter , so you are sure that you don't block >during gettimeofday().
Benno:
i *only* use rdtsc. I get *zero* dropouts. None. Moreover, I am amazed at the speed of certain things: for instance, reading 1024 bytes of data from the soundcard, for example, takes 5-6usec, including the overhead of rdtsc. This is outstanding!
Quasimodo carefully monitors its own timing with rdtsc, and reports on any missed internal deadlines. More precisely: it computes the number of usecs allowed per control cycle loop, and any time a control cycle takes longer than it should have, it reports that. The control cycle includes real-time audio generation, real-time audio output, real-time audio input if necessary, disk reads for stored sound playback etc. I repeat - I don't get *any* dropouts with Quasimodo using a 1.3ms audio buffer.
Only heavy disc activity and heavy computational activity by other threads affect it, and the latter can be avoided by running Quasimodo's DSP thread with RT priority.
>I've read the BeOS specs, and they claim to archieve >250 usec scheduling latencies, I was wondering if BeOS is stable in a 5ms >audio-MIDI latency enviroment , during high I/O.
when I use rdtsc to check on certain things that I expect to take 44100usec, and I notice that the variance that rdtsc reports is only 10-250usec, its seems likely to me that Linux can do this as well.
>P.S: I'm currently enhancing my benchmark to stress the OS even more, >through wasting a considerable CPU bandwith (let's say >80%), >using loops, after each wrtite() to /dev/dsp , do simulate a CPU hungry synth, >I use now the RDTSC do do measurements, to get even more accurate results. >I will post the URL plus some benchmark results soon.
I have to say again that I think your emphasis on being able to do heavy disk IO during realtime synthesis is really artificial. Yes, Windows can do this, but the price of it is vastly increased overall latency (and much slower disk performance for other applications). The Gigasampler stuff doesn't do a lot of disk I/O by your benchmark's standards, and no, I don't believe that they got to 5ms without circumventing most of the Windows API.
Realtime software synthesis, as practised by every digital synthesizer (be it on a "computer" or a "synthesizer") isn't meant to be compatible with heavy (and/or random) disk I/O. That doesn't mean we shouldn't try to get Linux to work better, but I don't *want* to be able to do "cp /dev/zero /tmp" while I run a software synthesizer.
--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/
| |