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 :-
- SSP IRQ fires and status indicates xrun/BCE. SSP IRQ handler notifies
pipeline of XRUN.
- Pipeline XRUN handler runs through all components, DAI component
takes XRUN and check action with SSP driver. SSP indicates whether restart is needed.
DAI layer takes any XRUN actions.
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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware