Subject: Re: [linux-audio-dev] Re: Latency test (RTcmix/Linux)
From: Gary Scavone (gary_AT_ccrma.Stanford.EDU)
Date: Sat Jul 29 2000 - 20:07:35 EEST
>>BTW: what kind of buffersizes did you use ?
>>single threaded, multi threaded app ?
>>
>>with how much data did you prefill the DAC ?
>>eg. you open the card in fullduplex, stop it
>>prefill the DAC (write() ) with num frags x fragsize
>>bytes, and then begin the cycle
>>while(1)
>>{
>> read() fragment from soundcard
>> write() fragment to soundcard
>>}
>>
>>the theoretical latency should be exactly
>>num_frags x fragsize
>>
>>I was wondering how the latency measured externally
>>differed from this theoretical value.
>>did you use analog IO ?
OK, I have a "duplex-mode" class that opens the device for operation.
In some APIs, that means you open one device and read/write to that
(OSS). In ALSA, you actually open two separate devices, though it
might be doing something else below the API that I don't know about.
In the class, I fill buffers and offset the read and write routines by
BUFFER_SIZE/2. This is all single-threaded. My routines block at
reads and writes until the audio device(s) are ready.
In ALSA, there's a "params.buf.block.frags_max" parameter. I normally
set that to 3, but in my tests I found that I could go to 2 and
improve latency. So, the best case latency results were with 2
fragments (again, I don't know exactly what is happening under the API
layer). At 22050 Hz, I was able to take my BUFFER_SIZE down to 64
sample frames without audible problems (which gave me about 18 ms
latency). At 44100 Hz, I was able to use 32 sample frame buffers
(which gave me about 10 ms latency). For the Delta 1010 under ALSA,
you actually have to feed it 10 channels of output data and read 12
channels of input data. I was only dealing with a single channel of
data. Of course, I didn't "write" and "read" zeros to the buffers for
the excess channels ... I just allocated a buffer of the correct size
for each direction and only wrote/read to the indices that I was
working with.
The Delta 1010 does analog i/o, which is what I was using. There is a
new add-on box you can buy for the 1010 that does digital i/o as well.
We'll probably buy one of those soon and hope some ALSA person updates
the driver for it! :-)
If it helps, I'll just send the code ... C++ STK code, very simple to
read.
--gary
>>On Sat, 29 Jul 2000, Gary Scavone wrote:
>>> Hi David,
>>>
>>> This is not exactly along the same lines as your previous email, but I
>>> did an audio i/o latency test a few weeks ago here at CCRMA for the
>>> Midiman Delta 1010 card (8 channels analog i/o plus S/PDIF). I had a
>>> scope hooked up to both the input and the output of the card and used
>>> a square-wave generator for input (patched through the scope). I
>>> wrote a simple STK program that read in a buffer of data and
>>> immediately read it out. At 22 KHz, I was able to get down to about
>>> 18 ms i/o delay. At 44.1 KHz, however, I got it down to about 10 ms.
>>> I was, of course, using the ALSA driver. I tried doing some
>>> FIFO_SCHED priority stuff, but that didn't really affect the latency
>>> (I didn't expect it would).
>>>
>>> *******************************************************
>>> * Gary Scavone *
>>> * Center for Computer Research in Music & Acoustics *
>>> * Stanford University *
>>> * gary_AT_ccrma.stanford.edu *
>>> * http://www-ccrma.stanford.edu/~gary/ *
>>> *******************************************************
>>
This archive was generated by hypermail 2b28 : Sat Jul 29 2000 - 20:44:26 EEST