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 ?
next prev 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).