[RFC 0/4] FIFO caused playback delay (latency) handling in soc

[RFC 0/4] FIFO caused playback delay (latency) handling in soc

[Peter Ujfalusi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

Hello,

There has been discussion in alsa-devel in this subject several times,
but no actual patches has been sent.

Based on the available information the latency caused by the HW buffer
on some systems can be handled by updating the runtime->delay.

It has been discussed, that the runtime->delay can also be updated
dynamically to show more accurate delay.

To further complicate things, in ASoC we could have more buffer in the
chain. To handle this we need soc level support.

This RFC series tries to do that in soc by:
- introducing a pcm_pointer wrapper
- in this wrapper we call the original pcm_pointer functions to get the
  DMA pointer
- introducing a new interface in dai_ops to ask the delay from the dais
- adding the cpu_dai and codec_dai returned delay to form the actual
  delay
- update the runtime->delay with this value.

With this approach none of the existing drivers need change, but they
can add support for specifying the FIFO caused delay.

In this series on top of the core changes the omap(3) code is updated
to take this delay reporting into use.
I have not added the support to the tlv320dac33 codec driver, since it
needs a bit more work, but along the same line it can be done, and if
the tlv320dac33 is hooked to omap McBSP than applications can know the
whole delay/latency on that path.

Since this is for RFC, I have based it on sound-2.6 topc/asoc branch,
which does not have the McBSP regcache nor the sidetone patches, but I
would like to get feedback on this method first than create a proper
series.

I have left out linux-omap from this RFC round, since the problem
is ALSA related.

Thank you,
Péter Ujfalusi

---
Peter Ujfalusi (4):
  ASoC: core: soc level wrapper for pcm_pointer callback
  ASoC: core: Add delay operation to snd_soc_dai_ops
  OMAP3: McBSP: Add interface for transmit FIFO state query
  ASoC: OMAP3: Report delay on playback caused by the internal FIFO

 arch/arm/plat-omap/include/plat/mcbsp.h |    4 +++
 arch/arm/plat-omap/mcbsp.c              |   27 ++++++++++++++++++++++++
 include/sound/soc-dai.h                 |    6 +++++
 sound/soc/omap/omap-mcbsp.c             |   26 +++++++++++++++++++++++
 sound/soc/soc-core.c                    |   34 ++++++++++++++++++++++++++++++-
 5 files changed, 96 insertions(+), 1 deletions(-)


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [RFC 0/4] FIFO caused playback delay (latency) handling in soc

[Mark Brown]

On Tue, Mar 02, 2010 at 03:39:47PM +0200, Peter Ujfalusi wrote:

> There has been discussion in alsa-devel in this subject several times,
> but no actual patches has been sent.

Well, it's never really been discussed in an ASoC context - most of the
interest has been on the PC audio side.  This is the first interest in
it from the embedded side.

This is pretty much what I would have implemented, aside from the
playback/capture thing I mentioned the only other thing that I'd suggest
is also adding a callback for the platform driver.  Many CPUs actually
introduce the latency in the DMA stream rather than in the interface,
for example by filling up a SRAM buffer as DaVinci currently does, and
it's more natural for them to keep track of the latency introduced in
the code that's managing the DMA.  For devices where the buffer is on
the interface the DAI makes sense.

Re: [RFC 0/4] FIFO caused playback delay (latency) handling in soc

[Raymond Yau]

2010/3/2 Peter Ujfalusi <peter.ujfalusi@nokia.com>

> Hello,
>
> There has been discussion in alsa-devel in this subject several times,
> but no actual patches has been sent.
>
> Based on the available information the latency caused by the HW buffer
> on some systems can be handled by updating the runtime->delay.
>
> It has been discussed, that the runtime->delay can also be updated
> dynamically to show more accurate delay.
>
> To further complicate things, in ASoC we could have more buffer in the
> chain. To handle this we need soc level support.
>
> This RFC series tries to do that in soc by:
> - introducing a pcm_pointer wrapper
> - in this wrapper we call the original pcm_pointer functions to get the
>  DMA pointer
> - introducing a new interface in dai_ops to ask the delay from the dais
> - adding the cpu_dai and codec_dai returned delay to form the actual
>  delay
> - update the runtime->delay with this value.
>
> With this approach none of the existing drivers need change, but they
> can add support for specifying the FIFO caused delay.
>
> In this series on top of the core changes the omap(3) code is updated
> to take this delay reporting into use.
> I have not added the support to the tlv320dac33 codec driver, since it
> needs a bit more work, but along the same line it can be done, and if
> the tlv320dac33 is hooked to omap McBSP than applications can know the
> whole delay/latency on that path.
>
> Since this is for RFC, I have based it on sound-2.6 topc/asoc branch,
> which does not have the McBSP regcache nor the sidetone patches, but I
> would like to get feedback on this method first than create a proper
> series.
>
> I have left out linux-omap from this RFC round, since the problem
> is ALSA related.
>
> Thank you,
> Péter Ujfalusi
>
> ---
> Peter Ujfalusi (4):
>  ASoC: core: soc level wrapper for pcm_pointer callback
>  ASoC: core: Add delay operation to snd_soc_dai_ops
>  OMAP3: McBSP: Add interface for transmit FIFO state query
>  ASoC: OMAP3: Report delay on playback caused by the internal FIFO
>
>  arch/arm/plat-omap/include/plat/mcbsp.h |    4 +++
>  arch/arm/plat-omap/mcbsp.c              |   27 ++++++++++++++++++++++++
>  include/sound/soc-dai.h                 |    6 +++++
>  sound/soc/omap/omap-mcbsp.c             |   26 +++++++++++++++++++++++
>  sound/soc/soc-core.c                    |   34
> ++++++++++++++++++++++++++++++-
>  5 files changed, 96 insertions(+), 1 deletions(-)
>
>
>
Do soc support snd_pcm_rewind() and snd_pcm_forward ?

Re: [RFC 0/4] FIFO caused playback delay (latency) handling in soc

[Mark Brown]

On Wed, Mar 03, 2010 at 07:29:23AM +0800, Raymond Yau wrote:

> Do soc support snd_pcm_rewind() and snd_pcm_forward ?

No driver demand yet, though it'd be trivially implemented if anyone
wanted to do it.

Re: [RFC 0/4] FIFO caused playback delay (latency) handling in soc

[Raymond Yau]

>> Do soc support snd_pcm_rewind() and snd_pcm_forward ?

>>No driver demand yet, though it'd be trivially implemented if anyone
>>wanted to do it.

if size of fifo is around 1x ~ 3x fames

How accucate do those media player need to allow A/V lip sync ,
Video is about 24 ~ 30 frames per seconds  and audio is 48000Hz ?