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