[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