ASoC: no-pcm (backend) error propagation

ASoC: no-pcm (backend) error propagation

[Frkuska, Joshua]

Hello,

I am working off of the 3.5.7 branch of the kernel using a frontend-backend approach for my driver. No additional patches have been added for ASoC/ALSA from the 3.5.7 kernel branch.

My question relates to the way the no-pcm (backend) propagates errors to the front end. My FE(frontend) consists of a cpu-dai, a pcm platform driver, and a dummy-codec. My BE(backend) consists of another cpu-dai, a non-pcm platform driver, and a real codec.
The non-pcm operates with the dmaengine but just in an autonomous fashion external to the PCM's knowledge.

I have the pcm-platform driver passing data to the FE cpu-dai and the backend platform then takes the data from the frontend's cpu-dai and passes it on to the BE cpu-dai, which then configures the codec-dai to get output.

In the frontend if/whenever there is an underrun error in the cpu-dai, I can directly call snd_pcm_stop to stop the stream and report the error state. I can do this because the substream->ops have properly been defined in the frontend pcm. However, in the backend, the substream->ops never get initialized and rightfully so since there isn't a valid pcm for the backend.

My question is, what is the correct/any way to let the frontend PCM stream know that an underrun has occurred in the backend? Is there a mechanism to handle this in ASoC? Looking through the code, I cannot find such a mechanism. I have a feeling that there should be something like snd_soc_pcm_stop to check to see if we are in a FE/BE configuration and act accordingly to stop the FE PCM stream and report errors.

Again, perhaps such a mechanism exists and if so any help would be appreciated.

Thanks for your time and any comments/suggestions,

Joshua

Re: ASoC: no-pcm (backend) error propagation

[Liam Girdwood]

On Wed, 2013-02-27 at 02:21 +0000, Frkuska, Joshua wrote:
> Hello,
> 
> I am working off of the 3.5.7 branch of the kernel using a frontend-backend approach for my driver. No additional patches have been added for ASoC/ALSA from the 3.5.7 kernel branch.
> 
> My question relates to the way the no-pcm (backend) propagates errors to the front end. My FE(frontend) consists of a cpu-dai, a pcm platform driver, and a dummy-codec. My BE(backend) consists of another cpu-dai, a non-pcm platform driver, and a real codec.
> The non-pcm operates with the dmaengine but just in an autonomous fashion external to the PCM's knowledge.
> 
> I have the pcm-platform driver passing data to the FE cpu-dai and the backend platform then takes the data from the frontend's cpu-dai and passes it on to the BE cpu-dai, which then configures the codec-dai to get output.
> 
> In the frontend if/whenever there is an underrun error in the cpu-dai, I can directly call snd_pcm_stop to stop the stream and report the error state. I can do this because the substream->ops have properly been defined in the frontend pcm. However, in the backend, the substream->ops never get initialized and rightfully so since there isn't a valid pcm for the backend.
> 
> My question is, what is the correct/any way to let the frontend PCM stream know that an underrun has occurred in the backend? Is there a mechanism to handle this in ASoC? Looking through the code, I cannot find such a mechanism. I have a feeling that there should be something like snd_soc_pcm_stop to check to see if we are in a FE/BE configuration and act accordingly to stop the FE PCM stream and report errors.
> 

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. 

Regards

Liam

Re: ASoC: no-pcm (backend) error propagation

[Pierre-Louis Bossart]

> 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

Re: ASoC: no-pcm (backend) error propagation

[Liam Girdwood]

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 

Re: ASoC: no-pcm (backend) error propagation

[Frkuska, Joshua]

> 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,

Joshua
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC: no-pcm (backend) error propagation

[Liam Girdwood]

Re-flowed.

On Mon, 2013-03-04 at 01:30 +0000, Frkuska, Joshua wrote:

> 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.
> 

There is some re parenting code in soc-pcm.c dpcm_be_reparent(). It
shows the list connect each FE and BE and should give some ideas for the
back routing. 

Liam

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC: no-pcm (backend) error propagation

[Frkuska, Joshua]

> On Mon, 2013-03-04 at 01:30 +0000, Frkuska, Joshua wrote:
> 
> > 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.
> >
> 
> There is some re parenting code in soc-pcm.c dpcm_be_reparent(). It shows the
> list connect each FE and BE and should give some ideas for the back routing.
> 
Liam,

Thank you for your assistance, if I feel like I may have a potential solution, I will post a patch with the ideas.

Best regards,

Joshua
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC: no-pcm (backend) error propagation

[Frkuska, Joshua]

> On Wed, 2013-02-27 at 02:21 +0000, Frkuska, Joshua wrote:
> > Hello,
> >
> > I am working off of the 3.5.7 branch of the kernel using a frontend-backend
> approach for my driver. No additional patches have been added for ASoC/ALSA
> from the 3.5.7 kernel branch.
> >
> > My question relates to the way the no-pcm (backend) propagates errors to the
> front end. My FE(frontend) consists of a cpu-dai, a pcm platform driver, and a
> dummy-codec. My BE(backend) consists of another cpu-dai, a non-pcm platform
> driver, and a real codec.
> > The non-pcm operates with the dmaengine but just in an autonomous fashion
> external to the PCM's knowledge.
> >
> > I have the pcm-platform driver passing data to the FE cpu-dai and the backend
> platform then takes the data from the frontend's cpu-dai and passes it on to the
> BE cpu-dai, which then configures the codec-dai to get output.
> >
> > In the frontend if/whenever there is an underrun error in the cpu-dai, I can
> directly call snd_pcm_stop to stop the stream and report the error state. I can
> do this because the substream->ops have properly been defined in the frontend
> pcm. However, in the backend, the substream->ops never get initialized and
> rightfully so since there isn't a valid pcm for the backend.
> >
> > My question is, what is the correct/any way to let the frontend PCM stream
> know that an underrun has occurred in the backend? Is there a mechanism to
> handle this in ASoC? Looking through the code, I cannot find such a mechanism.
> I have a feeling that there should be something like snd_soc_pcm_stop to check
> to see if we are in a FE/BE configuration and act accordingly to stop the FE PCM
> stream and report errors.
> >
> 
> 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.
> 

With architectures that have an audio DSP, I think it makes sense to do it as it is done with OMAP where underruns can be handled internally by the DSP. The need came up for me because in my setup there isn’t a dedicated audio DSP and the BE components are on the same SoC as the FE, running/controlled by linux. (with the exception of the codec)

> 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.
> 

May I ask what FE PCM xrun mechanism you are referring to? I am unaware of this mechanism in ASoC. Along with errors, delay too may want to be considered from the backend as the entire data path starts at the FE and ends at the BE. (Just a thought)

> It looks like some new code is required here to get this working correctly for BEs.

I am interested in exploring what is necessary to get FE/BE working in the fashion discussed above and still have everything work with the audio DSP model.

Thank you again for your time,

Joshua
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC: no-pcm (backend) error propagation

[Liam Girdwood]

On Thu, 2013-02-28 at 00:49 +0000, Frkuska, Joshua wrote:
> > On Wed, 2013-02-27 at 02:21 +0000, Frkuska, Joshua wrote:
> > > Hello,
> > >
> > > I am working off of the 3.5.7 branch of the kernel using a frontend-backend
> > approach for my driver. No additional patches have been added for ASoC/ALSA
> > from the 3.5.7 kernel branch.
> > >
> > > My question relates to the way the no-pcm (backend) propagates errors to the
> > front end. My FE(frontend) consists of a cpu-dai, a pcm platform driver, and a
> > dummy-codec. My BE(backend) consists of another cpu-dai, a non-pcm platform
> > driver, and a real codec.
> > > The non-pcm operates with the dmaengine but just in an autonomous fashion
> > external to the PCM's knowledge.
> > >
> > > I have the pcm-platform driver passing data to the FE cpu-dai and the backend
> > platform then takes the data from the frontend's cpu-dai and passes it on to the
> > BE cpu-dai, which then configures the codec-dai to get output.
> > >
> > > In the frontend if/whenever there is an underrun error in the cpu-dai, I can
> > directly call snd_pcm_stop to stop the stream and report the error state. I can
> > do this because the substream->ops have properly been defined in the frontend
> > pcm. However, in the backend, the substream->ops never get initialized and
> > rightfully so since there isn't a valid pcm for the backend.
> > >
> > > My question is, what is the correct/any way to let the frontend PCM stream
> > know that an underrun has occurred in the backend? Is there a mechanism to
> > handle this in ASoC? Looking through the code, I cannot find such a mechanism.
> > I have a feeling that there should be something like snd_soc_pcm_stop to check
> > to see if we are in a FE/BE configuration and act accordingly to stop the FE PCM
> > stream and report errors.
> > >
> > 
> > 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.
> > 
> 
> With architectures that have an audio DSP, I think it makes sense to do it as it is done with OMAP where underruns can be handled internally by the DSP. The need came up for me because in my setup there isn’t a dedicated audio DSP and the BE components are on the same SoC as the FE, running/controlled by linux. (with the exception of the codec)
> 

So if there is no audio DSP architecture then I assume you have some sort of DAI switch matrix/mixers in the HW and you don't do any ASRC ? 

> > 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.
> > 
> 
> May I ask what FE PCM xrun mechanism you are referring to? I am unaware of this mechanism in ASoC. Along with errors, delay too may want to be considered from the backend as the entire data path starts at the FE and ends at the BE. (Just a thought)

ALSA can report PCM (FE) xruns up the stack. A quick grep in sound/core/ for XRUN will show the mechanism.

There is a delay reporting for DAIs, but it would need some extra logic to extend it to BE DAIs atm. 

Liam

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC: no-pcm (backend) error propagation

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]

On Fri, Mar 01, 2013 at 09:24:50PM +0000, Liam Girdwood wrote:
> On Thu, 2013-02-28 at 00:49 +0000, Frkuska, Joshua wrote:

Reflowed both sets of text into 80 columns...

> > With architectures that have an audio DSP, I think it makes sense to
> > do it as it is done with OMAP where underruns can be handled
> > internally by the DSP. The need came up for me because in my setup
> > there isn’t a dedicated audio DSP and the BE components are on the
> > same SoC as the FE, running/controlled by linux. (with the exception
> > of the codec)

> So if there is no audio DSP architecture then I assume you have some
> sort of DAI switch matrix/mixers in the HW and you don't do any ASRC ? 

The modern Samsung SoCs are an example of this in mainline (currently a
bit bodged rather than using soc-pcm) - they've got a couple of DAIs
with a simple mixer that outputs on a single physical output, requiring
that both streams be at the same sample rate.  There's no meaningful
handling of underruns to do except for propagate them back up to the
application layer, each stream can error totally independently.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC: no-pcm (backend) error propagation

[Frkuska, Joshua]

> On Thu, 2013-02-28 at 00:49 +0000, Frkuska, Joshua wrote:
> > > On Wed, 2013-02-27 at 02:21 +0000, Frkuska, Joshua wrote:
> > > > Hello,
> > > >
> > > > I am working off of the 3.5.7 branch of the kernel using a
> > > > frontend-backend
> > > approach for my driver. No additional patches have been added for
> > > ASoC/ALSA from the 3.5.7 kernel branch.
> > > >
> > > > My question relates to the way the no-pcm (backend) propagates
> > > > errors to the
> > > front end. My FE(frontend) consists of a cpu-dai, a pcm platform
> > > driver, and a dummy-codec. My BE(backend) consists of another
> > > cpu-dai, a non-pcm platform driver, and a real codec.
> > > > The non-pcm operates with the dmaengine but just in an autonomous
> > > > fashion
> > > external to the PCM's knowledge.
> > > >
> > > > I have the pcm-platform driver passing data to the FE cpu-dai and
> > > > the backend
> > > platform then takes the data from the frontend's cpu-dai and passes
> > > it on to the BE cpu-dai, which then configures the codec-dai to get output.
> > > >
> > > > In the frontend if/whenever there is an underrun error in the
> > > > cpu-dai, I can
> > > directly call snd_pcm_stop to stop the stream and report the error
> > > state. I can do this because the substream->ops have properly been
> > > defined in the frontend pcm. However, in the backend, the
> > > substream->ops never get initialized and rightfully so since there isn't a valid
> pcm for the backend.
> > > >
> > > > My question is, what is the correct/any way to let the frontend
> > > > PCM stream
> > > know that an underrun has occurred in the backend? Is there a
> > > mechanism to handle this in ASoC? Looking through the code, I cannot find
> such a mechanism.
> > > I have a feeling that there should be something like
> > > snd_soc_pcm_stop to check to see if we are in a FE/BE configuration
> > > and act accordingly to stop the FE PCM stream and report errors.
> > > >
> > >
> > > 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.
> > >
> >
> > With architectures that have an audio DSP, I think it makes sense to
> > do it as it is done with OMAP where underruns can be handled
> > internally by the DSP. The need came up for me because in my setup
> > there isn’t a dedicated audio DSP and the BE components are on the
> > same SoC as the FE, running/controlled by linux. (with the exception
> > of the codec)
> >
> 
> So if there is no audio DSP architecture then I assume you have some sort of DAI
> switch matrix/mixers in the HW and you don't do any ASRC ?
> 

There are DAI switch mixers and the ASRC is the FE cpu_dai. The BE can be the other system CPU DAIs for digital audio interfacing. In this way, resampling can occur with any CPU_DAI in the system.

> > > 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.
> > >
> >
> > May I ask what FE PCM xrun mechanism you are referring to? I am
> > unaware of this mechanism in ASoC. Along with errors, delay too may
> > want to be considered from the backend as the entire data path starts
> > at the FE and ends at the BE. (Just a thought)
> 
> ALSA can report PCM (FE) xruns up the stack. A quick grep in sound/core/ for
> XRUN will show the mechanism.
> 
> There is a delay reporting for DAIs, but it would need some extra logic to extend
> it to BE DAIs atm.

Thank you very much for confirming the delay-reporting. I am also familiar with the ALSA XRUN mechanism that you mention.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel