Péter Ujfalusi

alsabat failed on mtl-sdw but it looks like a false positive as #4908 have the alsabat fail on the same CI device.

Changes since v3: - separate out the revert of #4840 patch - Update the commit message for the second patch (was the first previously)

@ranj063, this is what I was thinking of: #4899

I think this will enable rpm for the legacy stack: ``` options snd-hda-intel dyndbg=+pmf power_save=2 power_save_controller=1 ``` This will cause rpm suspend after two seconds of inactivity.

@plbossart, with an improved alsaconformance test the reported delay is taken into account for the rate validation and it passes fine: https://github.com/ujfalusi/chromeos-audiotest/tree/topic/pcm-delay I really don't know how that can be...

> Can you try to disable this PCM device "Deepbuffer HDA Analog " to see if we have the problem? > > i see this sequence in the trace >...

Too bad that the full dmesg is not available in CI (34110, 34168), but it appears that neither aplay or arecord terminates with the `pkill -9` in the previous iteration....

I have managed to reproduce the issue on the CI device. The test case fails, the kernel log shows that both PCM (:0,0 and :0,31) is closed: ``` [ 1641.239184]...

interesting... If I break out from the test to avoid the second batch of aplay to be started with: ```diff diff --git a/test-case/multiple-pipeline.sh b/test-case/multiple-pipeline.sh index d075ba166f27..f7bb93e59d56 100755 --- a/test-case/multiple-pipeline.sh +++...

In think it is something PM related and I think it is not really in the sound (SOF) stack, but I can be completely wrong. I have tried to get...