All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Liam Girdwood <liam.r.girdwood@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: Wed, 27 Feb 2013 09:43:52 -0600	[thread overview]
Message-ID: <512E29B8.8050708@linux.intel.com> (raw)
In-Reply-To: <1361953433.28121.33.camel@vega>


> 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

  reply	other threads:[~2013-02-27 15:44 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 [this message]
2013-03-01 21:25     ` Liam Girdwood
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=512E29B8.8050708@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=Joshua_Frkuska@mentor.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=lrg@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.