[BUG] Audio become 'metallic' after few pause/resume cycle

[ujfalusi]

Describe the bug Doing pause/resume cycle can result in 'metallic' sounding audio. The number of cycles are random, but it can be reproduced with few iterations. Further pause/resume can recover from the 'metallic' sound to be clean. It is similar, but not the same as https://github.com/thesofproject/sof/issues/7478 was.

To Reproduce Play audio with aplay: On SDW (MTL/TGL): aplay -iv -Dhw:0,2 file.wav On HDA: aplay -iv -Dhw:0,0 file.wav

Press < SPACE > to pause, press < SPACE > to resume, keep some time between the key presses. It can be reproduced by holding the < SPACE > and releasing randomly.

Reproduction Rate 2/10 - not all pause/resume cycle will result 'metallic' distortion

Expected behavior Audio is clean after each resume.

Impact Audio quality degrades if pause/resume is used severely

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: topic/sof-dev or distro kernel (6.8.1 and 6.7.9 tested)
   • SOF: main HEAD, v2.9 branch or released firmware (2023.12.1, 2023.09.2 tested on MTL)
2. Name of the topology file
   • Topology:
     • MTL: sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplg
     • TGL: sof-hda-generic.tplg (HDA) and sof-tgl-rt715-rt711-rt1308-mono.tplg (SDW)
3. Name of the platform(s) on which the bug is observed.
   • Platform: TGL (HDA, SDW ), MTL (SDW)

[kv2019i]

I could now reproduce this with aplay and SOF 2.9 release on a TGL UP i11 board.

[kv2019i]

I can NOT reproduce this on a MTL SDW device using tplg intel/sof-ace-tplg/sof-mtl-rt713-l0-rt1316-l12.tplg , sof-dev f80b8f32f46500e1d71f9d9061090b683f813900 used as driver and SOF2.9 (tag sof-2.9) used as FW. Tried also a few different FW and kernel versions, but could not reproduce the error. With same kernel+FW, I could easily reproduce on the TGL i11 UP board.

[ujfalusi]

@kv2019i, I just tried that sof-dev commit on my MTL SDW device which loads sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplg and I can reproduce the issue. I cannot test the 2.9 due to signature issues, only released firmware (2.8.1). Basically you can just hold < SPACE > continuously and if you hear a metallic 'glitch' you release it. There must not be a single metallic 'glitch'.

amixer -c0 sset 'Main Amplifier' 40
amixer -c0 sset 'rt1316-1 DAC' on
aplay -Dplughw:0,2 -i /home/sof/work/samples/came_back_haunted_48K_32bit.wav

After few seconds of holding < SPACE > I can hear metallic 'glitches' instead of the choppy pause/resume.

[plbossart]

Are you sure the metallic noises are not part of the track "came_back_haunted_48K_32bit.wav" haha?

[ujfalusi]

OK, so bare with me on this :D

In short, the blamed commit is: 9831a9ded770 ("audio: dai-zephyr: reset DMA buffer cursors on TRIGGER_RELEASE")

But it is a bit more complicated than that as the commit actually fixes the 'metallic' sound :confused:

I encountered with the issue on upx-i11 first. It is an HDA device with FW built from sof:main, then I confirmed it on two SDW device with released (2.8.1 and older) firmware as they use production key.

I knew that I have once fixed similar issue, I started from there and then with long and painful bisect I ended up at this commit and indeed, reverting it fixes the issue on upx-i11 (HDA). I was able to try a production signed 2.9 just now on the two SDW device (which includes this commit) and voila, the issue is fixed.

So, the commit fixes non HDA-DMA serviced dais while breaking the HDA-DMA serviced ones. Nice, I'm not yet sure what information we can use to fix the regression while keeping the fix applied when needed..

FYI, @plbossart, @kv2019i, @lgirdwood, @dbaluta

[plbossart]

nice find @ujfalusi, surprising results!

I would put my money on the special 'pause' state for the HDaudio DMA. Other DMAs don't have this concept, so there's probably something getting in the way or missing.