Le Mon, 23 Jun 2014 18:20:43 +0200, "Max Schmidt" <schmidti444@xxxxxx> a écrit : Hi, I am not an audio developer but I think the LAD list is a better place for such highly technical issues. I also think most developers that want a constant audio latency with their application will use the JACK API instead of the ALSA API. http://lists.linuxaudio.org/listinfo/linux-audio-dev > Hey all, > > first a big hello to everyone since I'm new to this mailing-list. > I've had a look regarding this issue here and in generell in the > internet but didn't find anything relating. So, sorry if I overlooked > something. I've got a BeagleBone Black (ARM Cortex A 8 µP) with an > Audio-Cape (using McAsp and ALSA-Davinci-Drivers) and wrote an mmap > based playback-capture application (both devices "hw:0,0"). The > important thing is that the application needs a constant delay (not > necessarily small) between the start of the playback and the capture > stream. So when looping back the signal to the microfone the first > played sample e.g. always (even after a restart of the BeagleBone or > the app) has a delay in the capture stream of exactly 80 samples > (when e.g. played with 48 kHz), and once measured can be seen as > constant. To realize that I use the ALSA API function > "snd_pcm_link(c_handle, p_handle)". When starting the playback stream > (and therefore linked capture stream as welll) manually its buffer > already is filled. There is no buffer underrun/overrun recovery. It > already works quite fine but I still have some questions and it would > be really nice if someone can help: 1) Looking at a plot of multiple > measurements of looped back and captured square waves (or sines) > there still is a jitter of about two to four samples (at 48 kHz; > which is about 40 to 80 ms), no matter if I run it as RT-app (energy > save modes etc. disabled, just important Processes have a higher > Priority e.g. EDMA) or normal app. Please correct me if I'm wrong, > but as far as I understand when the streams are linked, at start the > processor is going through a linked list triggering all linked > streams. And the trigger start is an atomic process so shouldn't get > interrupted. Shouldn't it always take the same time between starting > the playback and capture stream then? And if yes, where could the > variable start delay come from? 2) Looking at the time stamp of both > streams it tells that the difference between the start trigger > normally is between 2 to 7 ms. What, I think, does not really fit to > the observation written above since then there normally should be no > big sample jitter at 48 kHz. Are the time stamp values not precise > enough (actually how precise are the time stamps, just that they can > show microseconds does not imply that the resolution really is > microseconds, or am I wrong?) or are they correct and the difference > in latency seen in measured plots comes from somewhere else? Delay > due to Hardware should be constant so the issue must have something > to do with ALSA or Linux. Would be nice if someone can help or has an > idea! Tipps for an improvement are wlecome as well! Many thanks and > cheers! ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
