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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
