From: Liam Girdwood <liam.r.girdwood@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@ti.com>,
"Frkuska, Joshua" <Joshua_Frkuska@mentor.com>
Subject: Re: ASoC: no-pcm (backend) error propagation
Date: Fri, 01 Mar 2013 21:25:13 +0000 [thread overview]
Message-ID: <1362173113.4439.46.camel@loki> (raw)
In-Reply-To: <512E29B8.8050708@linux.intel.com>
On Wed, 2013-02-27 at 09:43 -0600, Pierre-Louis Bossart wrote:
> > It was originally intended that any underrun / overrun issues in a BE
> > DAI would be handled internally by the audio DSP (and this worked well
> > with the OMAP4 ABE). However, it is probably a good a idea to have a
> > better mechanism for reporting BE xrun issues up the stack to the host
> > CPU side too.
> >
> > Currently the FE PCM xrun mechanism and FE pointer() callback could be
> > used by the host to get the size of any FE:BE underrun/overrun. This
> > isn't ideal and wont work when there can be multiple BEs for a FE.
> >
> > It looks like some new code is required here to get this working
> > correctly for BEs.
>
>
> My view is that that underruns at the DSP level are fatal anyway, and
> that they a) should be avoided with proper real-time designs and b) they
> should be logged as error conditions to debug should they occur, not be
> tied to a FE. It would be really complicated to add code to
> back-propagate the errors, and if you have mixing/routing what
> individual FEs would do when this is a system error really.
> -Pierre
I agree, it would mostly be useful for DSP debug purposes e.g. things
like DSP clock scaling/gating, FW errors. It was certainly never an
issue with the OMAP ABE and we wont need it for SST audio either.
Fwiw, it may not even be too complicated to implement since the BE PCM
is a subset of the standard PCM and there is some code that already back
propagates the routing when we re-parent BE's. It really depends on
whether anyone cares enough to scope out a solution.
Liam
next prev parent reply other threads:[~2013-03-01 21:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-27 2:21 ASoC: no-pcm (backend) error propagation Frkuska, Joshua
2013-02-27 8:23 ` Liam Girdwood
2013-02-27 15:43 ` Pierre-Louis Bossart
2013-03-01 21:25 ` Liam Girdwood [this message]
2013-03-04 1:30 ` Frkuska, Joshua
2013-03-04 19:42 ` Liam Girdwood
2013-03-05 15:34 ` Frkuska, Joshua
2013-02-28 0:49 ` Frkuska, Joshua
2013-03-01 21:24 ` Liam Girdwood
2013-03-02 3:32 ` Mark Brown
2013-03-04 1:17 ` Frkuska, Joshua
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=1362173113.4439.46.camel@loki \
--to=liam.r.girdwood@linux.intel.com \
--cc=Joshua_Frkuska@mentor.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@ti.com \
--cc=pierre-louis.bossart@linux.intel.com \
/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).