[alsa-devel] ASoC: no-pcm (backend) error propagation
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
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
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
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
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
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
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
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
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
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.
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.
participants (4)
-
Frkuska, Joshua -
Liam Girdwood -
Mark Brown -
Pierre-Louis Bossart