[alsa-devel] ASoC: no-pcm (backend) error propagation

Frkuska, Joshua Joshua_Frkuska at mentor.com
Mon Mar 4 02:30:52 CET 2013

> From: Liam Girdwood Sent: Saturday, March 02, 2013 6:25 AM
> 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.

I am currently heading in this direction. In my setup, BE underruns are not fatal, especially if there is a throughput mismatch on the frontend and backend regarding dma transferring. The application needs to be made aware of the underrun in the BE to be able to dynamically adjust the dma watermark of the BE dai and potentially rebalance the throughput or adjust latency in the data stream.

If you could tell me the area you have in mind for the routing back propagation when re-parenting, I can study that, before creating something that isn’t inline with the existing code.

Thanks in advanced,


More information about the Alsa-devel mailing list