[alsa-devel] need help with io plugin programming: how to add delay ?

[Stefan Schoenleitner]

Hi,

Mads Kiilerich wrote:   
> 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.

I already thought that this would help.
So the alsa plugin would then fill some large buffer in my daemon
application and instead of receiving the data from a socket I would
have it available in some application buffer already.
Thus I could just read the frames from the application
buffer each 20ms and send them over UART to the DSP.

However, right now I found out that there seems to be no way
to execute *anything* each 20ms +/- 1ms.

So far I tried

	* nanosleep()
	* pthread_cond_timed_wait()
	* usleep()

I'm looking forward to try

	* HPET
	* RTC
	* setitimer()
	* alsa timers ?
	* anything else ?

I don't understand why all the function I have tried
so far have microsecond or even nanosecond precision and in the
end I'm off not for some nano- or microseconds, but for a full 15ms !
This is really bad :(


>> 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.

Indeed.


> 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.

As you said it's a different 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.

I looked at some code already.
Generally speaking it looks good, but it also uses 32 bit floating
point format for example (while I would need 8Khz 16bit LE).
It seems a little bit of a detour if I use:

ALSA --> jack io plugin --> jackd --> jack-client --> resample and change format --> my application

instead of

ALSA --> my plugin --> my application


As I said above, right now the problem is not even fully alsa related.
It is how I can execute something (e.g. my uart send code) each 20ms +/- 1ms.


>> 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.

Yes, I will have to deal with this as well :(
However, from time to time an overflow/underrun should be ok as long it
is generally working I guess.

Thanks for your inspiring words,
stefan