Constant delay between starting a playback and a capture stream

Constant delay between starting a playback and a capture stream

[Max Schmidt]

   Hi all,

   I first wrote this email to the ALSA user mailing list since I didn't
   know if it's appropriate to write to the ALSA dev list as I'm not
   directly involved in the project. I was suggested to better try it
   here. So, I'm sorry if this email is an inconvenience.

   See below my original post.
   Thanks and greetings!

   Gesendet: Montag, 23. Juni 2014 um 18:20 Uhr
   Von: "Max Schmidt" <schmidti444@web.de>
   An: alsa-user@lists.sourceforge.net
   Betreff: Constant delay between starting a playback and a capture
   stream
   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!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Constant delay between starting a playback and a capture stream

[Clemens Ladisch]

Max Schmidt wrote:
> 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.
> To realize that I use the ALSA API function "snd_pcm_link(c_handle,
> p_handle)".
>
> 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.

Yes.

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

Hardware accesses can be quite nondeterministic.  And if the driver is
not written properly, the start trigger will do all the DMA stream
initialization that should have been done when preparing the device.
(mcasp_start_tx() has a busy loop waiting for the device.)

There is hardware that actually supports starting two streams at exactly
the same time (by setting two bits in the same register).  Obviously,
this hardware or its driver doesn't support this.


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Constant delay between starting a playback and a capture stream

[Max Schmidt]

   Hi Clemens,

   thanks for your helpfull answer!

   Regards,
   Max

   Gesendet: Sonntag, 29. Juni 2014 um 20:21 Uhr
   Von: "Clemens Ladisch" <clemens@ladisch.de>
   An: "Max Schmidt" <schmidti444@web.de>, alsa-devel@alsa-project.org
   Betreff: Re: [alsa-devel] Constant delay between starting a playback
   and a capture stream
   Max Schmidt wrote:
   > 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.
   > To realize that I use the ALSA API function "snd_pcm_link(c_handle,
   > p_handle)".
   >
   > 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.
   Yes.
   > 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?
   Hardware accesses can be quite nondeterministic. And if the driver is
   not written properly, the start trigger will do all the DMA stream
   initialization that should have been done when preparing the device.
   (mcasp_start_tx() has a busy loop waiting for the device.)
   There is hardware that actually supports starting two streams at
   exactly
   the same time (by setting two bits in the same register). Obviously,
   this hardware or its driver doesn't support this.
   Regards,
   Clemens
   _______________________________________________
   Alsa-devel mailing list
   Alsa-devel@alsa-project.org
   [1]http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

References

   1. http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Alsa-user] Constant delay between starting a playback and a capture stream

[Max Schmidt]

   Hi,

   just for correction if someone will ever read my question again:
   of course it's microseconds and not milliseconds

   Sorry for the disturbance and regards