[alsa-devel] 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.