[Sound-open-firmware] [PATCH] dai: xrun: dont stop and restart DAI on XRUN recovery

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Fri Nov 17 16:47:56 CET 2017


On 11/17/17 9:08 AM, Liam Girdwood wrote:
> On Fri, 2017-11-17 at 08:35 -0600, Pierre-Louis Bossart wrote:
>> On 11/16/17 4:01 PM, Liam Girdwood wrote:
>>> WiP: The DAI should not be stopped and the restarted on XRUNs
>>
>> Are you sure about this one? if you have an xrun leading to a channel
>> swap, that's not something you could ever recover from?
>>
> 
> This was why it was WiP :)

ok, the commit title is also WiP then.

> I'm planning a patch for the SSP part later, but in general the DAI
> component would pass the XRUN onto the SSP driver and await a return on
> how to handle it. e.g. SSP driver error status could indicate whether we
> need to restart SSP (due to BCE or underrun or overruns).
> 
> Flow would go something like :-
> 
> 1) SSP IRQ fires and status indicates xrun/BCE. SSP IRQ handler notifies
> pipeline of XRUN.
> 
> 2) Pipeline XRUN handler runs through all components, DAI component
> takes XRUN and check action with SSP driver. SSP indicates whether
> restart is needed.
> 
> 3) DAI layer takes any XRUN actions.
> 
> 4) Playback continues.

humm, this flow looks reasonable but will need some platform/debug 
configurability. There are quite a few issues with xruns and sometimes 
the SSP guarantees that the channel swap won't happen, but in others an 
xrun on RX leads to issues on TX, with all sorts of chicken bits 
disabling or enabling work-arounds. So for your point #2 the SSP driver 
would need to be quite smart or be told through an IPC config what to do 
in the event of an xrun (conceal, report, stop, interface reset, DSP 
reset, etc) depending on the paranoia level tolerated on the platform.
As the paranoid-in-residence I'd like to make sure there are zero 
underflows tolerated during integration stages to force issues to pop-up 
in test reports...

> 
> Liam
> 
> 
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
> 



More information about the Sound-open-firmware mailing list