Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ujfalusi opened this issue Mar 26, 2024 · 6 comments · Fixed by #8995
Closed

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

ujfalusi opened this issue Mar 26, 2024 · 6 comments · Fixed by #8995
Labels
bug Something isn't working as expected HDA Applies to HD-Audio bus for codec connection MTL Applies to Meteor Lake platform P2 Critical bugs or normal features SDW SoundWire TGL Applies to Tiger Lake

Comments

@ujfalusi
Copy link
Contributor

ujfalusi commented Mar 26, 2024

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

  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)
@ujfalusi ujfalusi added the bug Something isn't working as expected label Mar 26, 2024
@kv2019i kv2019i added TGL Applies to Tiger Lake MTL Applies to Meteor Lake platform labels Mar 26, 2024
@kv2019i
Copy link
Collaborator

kv2019i commented Mar 26, 2024

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

@kv2019i
Copy link
Collaborator

kv2019i commented 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
Copy link
Contributor Author

ujfalusi commented 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'.

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.

@kv2019i kv2019i added HDA Applies to HD-Audio bus for codec connection SDW SoundWire labels Mar 27, 2024
@plbossart
Copy link
Member

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

@ujfalusi
Copy link
Contributor Author

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

ujfalusi added a commit to ujfalusi/sof that referenced this issue Mar 28, 2024
…RIGGER_RELEASE

During DMA stop/config/start the read/write pointer of HD-DMA is not
reset unlike other DMAs (GPDMA, DMAC).

Only call the audio_stream_reset() if the link is not serviced by HD-DMA.

Link: thesofproject#8986
Fixes: 9831a9d ("audio: dai-zephyr: reset DMA buffer cursors on TRIGGER_RELEASE")
Signed-off-by: Peter Ujfalusi <[email protected]>
@plbossart
Copy link
Member

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.

@abonislawski abonislawski added the P2 Critical bugs or normal features label Apr 2, 2024
kv2019i pushed a commit that referenced this issue Apr 3, 2024
…RIGGER_RELEASE

During DMA stop/config/start the read/write pointer of HD-DMA is not
reset unlike other DMAs (GPDMA, DMAC).

Only call the audio_stream_reset() if the link is not serviced by HD-DMA.

Link: #8986
Fixes: 9831a9d ("audio: dai-zephyr: reset DMA buffer cursors on TRIGGER_RELEASE")
Signed-off-by: Peter Ujfalusi <[email protected]>
eddy1021 pushed a commit to eddy1021/sof that referenced this issue Jul 15, 2024
…RIGGER_RELEASE

During DMA stop/config/start the read/write pointer of HD-DMA is not
reset unlike other DMAs (GPDMA, DMAC).

Only call the audio_stream_reset() if the link is not serviced by HD-DMA.

Link: thesofproject#8986
Fixes: 9831a9d ("audio: dai-zephyr: reset DMA buffer cursors on TRIGGER_RELEASE")
Signed-off-by: Peter Ujfalusi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as expected HDA Applies to HD-Audio bus for codec connection MTL Applies to Meteor Lake platform P2 Critical bugs or normal features SDW SoundWire TGL Applies to Tiger Lake
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants