Re: [linux-audio-dev] Latency .. fullduplex case

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Latency .. fullduplex case
From: sbenno_AT_gardena.net
Date: ti syys   14 1999 - 12:44:00 EDT


On Tue, 14 Sep 1999, Benjamin GOLINVAUX wrote:
> >I'm a little concerned about this term latency. To me latency
> >is a property of a one-shot process. An example would be interrupt
> >latency.
> [...]
> > Wouldn't this be more accurately be described as a "transport
> > delay" in line with the terminology of Control Theory? In the
> > terminology of DSP this would be called a linear phase shift
> > but thats probably not very clear :-).
>
> I'd prefer 'input to output latency' since 'latency' is such a widely
> accepted term.
>
> However, there is a _lot_ of confusion...
>
> Benno's latency program clearly deals with a one-shot latency from process
> to audio out.
> [oops... I'm not on alsa-devel here... Different lists, same people...]
>
> Could we safely assume that the iolatency is two times the one shot latency
> with two threads, one for audio in and one for audio out ? Any sync issues ?

No that is not true, IO-latency is not 2* output-latency, since
you read/write 1 fragment at time, you can just add one single fragment
to the buffer to keep things reliably.

example:
3x128 bytes =2.1ms , output latency
max peaks around 1.4ms
make the buffer one fragment larger = 4x128 bytes = 2.8ms latency

and then do the following: ( assuming you use blocking read/write)
write 4 fragments of silence to the output, at this point
both audio input and audio output will start (or alternatively you could
trigger the start via ioctl() after the write).

now enter into main loop:

while(1)
{
  read() from dsp to buffer
  do_processing()
  write() buffer to dsp
}

the first read should block since the write of the 4 fragments returns almost
immediately since it fits exactly into the audio buffer.
After the read returns, there are exactly 3 fragments in the output buffer
at this point you do your computations and assuming you use 90% of your CPU
for your DSP computations,
before the write() to /dev/dsp there are a bit over 2 fragments in the audio
buffer left. (if you do very little computations then there will be almost 3
fragments in the audio buffer left)

after the write() you have between 3 and 4 fragments in the buffer.
(depends from how much DSP computations you do in your do_processing()

plus add more 0.5ms for your soundcard's ADC ,
and you got a nice 3.3ms
:-)

Correct me please if I am missing something.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST