Repository navigation
[BUG] Audio become 'metallic' after few pause/resume cycle #8986
Description
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 #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
- 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)
- 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)
- Topology:
- Name of the platform(s) on which the bug is observed.
- Platform: TGL (HDA, SDW ), MTL (SDW)
Activity
kv2019i commentedon Mar 26, 2024
I could now reproduce this with aplay and SOF 2.9 release on a TGL UP i11 board.
kv2019i commentedon Mar 26, 2024
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 commentedon Mar 27, 2024
@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'.
After few seconds of holding < SPACE > I can hear metallic 'glitches' instead of the choppy pause/resume.
plbossart commentedon Mar 27, 2024
Are you sure the metallic noises are not part of the track "came_back_haunted_48K_32bit.wav" haha?
ujfalusi commentedon Mar 28, 2024
OK, so bare with me on this :D
In short, the blamed commit is: 9831a9d ("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 😕
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
audio: dai-zephyr: Do not reset the DMA buffer cursor for HD-DMA on T…
plbossart commentedon Mar 28, 2024
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.
audio: dai-zephyr: Do not reset the DMA buffer cursor for HD-DMA on T…
audio: dai-zephyr: Do not reset the DMA buffer cursor for HD-DMA on T…