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.