alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Raymond Yau <superquad.vortex2@gmail.com>
To: ALSA Development Mailing List <alsa-devel@alsa-project.org>
Subject: Re: [RFC 0/4] FIFO caused playback delay (latency) handling in soc
Date: Wed, 3 Mar 2010 07:29:23 +0800	[thread overview]
Message-ID: <4f3252891003021529h4cfe22a4wb5d8217da298a94f@mail.gmail.com> (raw)
In-Reply-To: <1267537191-25254-1-git-send-email-peter.ujfalusi@nokia.com>

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 ?

  parent reply	other threads:[~2010-03-02 23:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02 13:39 [RFC 0/4] FIFO caused playback delay (latency) handling in soc Peter Ujfalusi
2010-03-02 13:39 ` [RFC 1/4] ASoC: core: soc level wrapper for pcm_pointer callback Peter Ujfalusi
2010-03-02 13:39 ` [RFC 2/4] ASoC: core: Add delay operation to snd_soc_dai_ops Peter Ujfalusi
2010-03-02 13:45   ` Mark Brown
2010-03-02 13:49     ` Peter Ujfalusi
2010-03-02 13:54       ` Mark Brown
2010-03-02 13:39 ` [RFC 3/4] OMAP3: McBSP: Add interface for transmit FIFO state query Peter Ujfalusi
2010-03-02 13:45   ` Mark Brown
2010-03-02 13:52   ` Eero Nurkkala
2010-03-02 13:58     ` Liam Girdwood
2010-03-02 14:02     ` Peter Ujfalusi
2010-03-02 14:06     ` Jarkko Nikula
2010-03-03  6:07       ` Eero Nurkkala
2010-03-03  7:03         ` Jarkko Nikula
2010-03-03 10:02           ` Peter Ujfalusi
2010-03-03 10:07             ` Peter Ujfalusi
2010-03-03 14:18             ` Jarkko Nikula
2010-03-03 15:01               ` Peter Ujfalusi
2010-03-04  7:30                 ` Peter Ujfalusi
2010-03-03 19:00             ` ext-Eero.Nurkkala
2010-03-03 19:07               ` ext-Eero.Nurkkala
2010-03-04  7:53                 ` Peter Ujfalusi
2010-03-04  8:09               ` Peter Ujfalusi
2010-03-04  8:46                 ` Eero Nurkkala
2010-03-02 13:39 ` [RFC 4/4] ASoC: OMAP3: Report delay on playback caused by the internal FIFO Peter Ujfalusi
2010-03-02 13:47   ` Mark Brown
2010-03-02 13:52     ` Peter Ujfalusi
2010-03-02 14:06       ` Mark Brown
2010-03-02 13:53 ` [RFC 0/4] FIFO caused playback delay (latency) handling in soc Mark Brown
2010-03-02 23:29 ` Raymond Yau [this message]
2010-03-03 10:03   ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2010-03-05  1:19 Raymond Yau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f3252891003021529h4cfe22a4wb5d8217da298a94f@mail.gmail.com \
    --to=superquad.vortex2@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).