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