Re: need help with io plugin programming: how to add delay ?

[Mads Kiilerich <mads@kiilerich.com>]

Stefan Schoenleitner wrote, On 12/23/2009 12:08 AM:
> However, the result is not satisfying at all as the delay between the received chunks varies and sometimes even takes a whole 15ms (!) longer (i.e. 35ms delay instead of 20ms).
>    
...
> As the calculation of the sleep time uses an *absolute* point of time
> as reference (which is takes before starting to poll() and recv() from the socket), all delay after the time measurement and before the actual sleep does not influence the precision, right ?
> For this reason I have no idea where the high delay variations are coming from.
> I mean how should it work with an alsa plugin if not even this simple simulation code works
> in a timely and precise manner ?
>
> * What am I doing wrong ?
>
> I thought of adding buffering so that the socket read operations do not have a strict timing schedule.
> However, as I said earlier, if the time for socket polling or recv varies, it does not influence the precision as an absolute point of time is used as timeout and the (absolute) start time measurement is done *before* all the socket operations.
> Thus I think that for this reason adding buffering would not make much difference here, right ?
>    

AFAIK ALSA gurantees no deadlines, so I think you will have to add a 
"sufficiently large" buffer somewhere - and make sure to handle 
over/underruns somehow anyway.

> Just before starting to write yet another implementation
> (the fourth one,

I did the same exercise. It _is_ really hard to get started writing 
sound applications and figure out which abstraction level and 
implementation to use and how to use it correctly.

I ended up coding for the pulseaudio API. My case was for 
http://bitbucket.org/kiilerix/tcpcam/ . The result isn't pretty, but it 
could have been worse. The result isn't very stable or understood in all 
details, but it is good enough for my case. This case is different than 
yours, but I had problems similar to yours when I tried to code for the 
ALSA api. My numbers also happens to be exactly the same as in your case.

> this time with jack)

Jack to some extent builds on top of ALSA, so jack can't do it any 
better than ALSA. But jack might use ALSA the right way and thus give 
you someting close to what you want. AFAIK.

> It is connected over UART at 460800 baud and requires exactly 160 16bit PCM samples
> with 8kHz sampling rate each 20ms for speech compression.
>    

It is my experience that it matters that two different oscillators never 
have exactly the same frequency, so over time you will get an over- or 
under-run.

/Mads