lkml.org 
[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: lantency scheduling benchmarks of audio playing tasks during high disk I/O
Date
From
>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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.037 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site