Repository navigation
[SDW] cannot restart playback after suspend while in pause #1328
Description
Using the -i flag to play with the PUSH_PAUSE/PUSH_RELEASE trigger works fine with SoundWire with the latest PRs
If we use rtcwake to force a system suspend while in pause, then we have errors on restart
root@jf-icl-rvp-hda-8:~# aplay -Dhw:0,0 chirp_5s.wav -i
Playing WAVE 'chirp_5s.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
=== PAUSE === Suspended. Trying resume. Failed. Restarting stream. Done.
aplay: do_pause:1508: pause release error: File descriptor in bad state
This is reproducible 100% of the time, so likely a bad state machine transition.
Activity
ranj063 commentedon Oct 16, 2019
@plbossart we fixed the same issue with HDA with this commit bf705ea
The fix for SDW might be similar.
plbossart commentedon Oct 16, 2019
Thanks @ranj063 I knew this issue sounded familiar.
I don't fully get the statement "paused streams do not get suspended", does this mean the TRIGGER_SUSPEND is not sent if a TRIGGER_PUSH_PAUSE was already sent? is this a feature from the framework or a bug on the SOF side?
Also I am not sure what the moral equivalent this HDaudio fix would be for SoundWire. And actually we do use the same GDMA as for SSP, so not sure if we need to do anything? Odd.
ranj063 commentedon Oct 16, 2019
Yes, this is from the framework. If the stream is not running, it isnt suspended and so no TRIGGER_SUSPEND is sent.
ranj063 commentedon Oct 16, 2019
The action we take to fix is in the BE. The problem with HDAudio was that the stream tag is retained for paused streams coming back from suspend when in fact it should be a new stream tag. So the fix basically suggests to clear the stream tag for all streams before suspending.
My wild guess knowing not much about SDW state machine is that the moral equivalent of this would be deprepare all stream before suspending
plbossart commentedon Oct 16, 2019
so what is the DSP state for this PCM device at this point?
On a resume, we re-prepare and reinitialize everything, but I guess we don't put the PCM device is the same state as it was before suspend.
ranj063 commentedon Oct 16, 2019
Im not sure of the state names for PCM devices, but as far as the DSP is concerned the PCM is not even started because it has just woken up from D3.
plbossart commentedon Oct 17, 2019
Additional traces show we are getting a TRIGGER_START on resume, even though the stream was paused, and we are not getting a TRIGGER_PAUSE_RELEASE.
Something's broken here. not sure why we get the start, or should we interpret the TRIGGER_START as just a means to restore the state in PAUSE?
dmesg_pause.log
plbossart commentedon Oct 17, 2019
After an afternoon of debug, I am nearly convinced there is no bug, and the nasty messages on the console are a feature - not an SOF bug. When using a long file, the playback does not exit as I suspected but does go on after the PAUSE_RELEASE - it was a coincidence due to the short files I was using.
With the traces added to https://github.com/plbossart/sound/tree/fix/pause-suspend, I was able to show that the BADFD messages are due to the ALSA core, not something that the SOF driver did.
When INFO_RESUME is not supported, ALSA will send a PREPARE ioctl so the PCM state will become PREPARED, which is not the expected state for the PAUSE_RELEASE. However we still get a TRIGGER_START and playback continues.
We should double-check that the playback is actually audible after the PAUSE_RELEASE (I only did those tests over SSH).
Traces attached with a "<<<" marker for relevant changes.
dmesg_pause5.log
@bardliao @ranj063 @RanderWang can you take a look and confirm my analysis, my brain is officially fried for the day.
bardliao commentedon Oct 18, 2019
@plbossart I checked it with legacy HDA driver and it has the same behavior. So it is not an SOF bug.
plbossart commentedon Oct 18, 2019
thanks @bardliao let's close then