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

[Liam Girdwood <liam.r.girdwood@linux.intel.com>]

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