[BUG][CML][UCM2]Speaker and headset has sound output at the same time after suspend-resume

[Liviali155]

Describe the bug
Speaker and headset has sound output at the same time after suspend-resume
Ctrl +c to stop paplay then paplay Right now again can not recovery,
Ctrl +c to stop paplay,wait about 20s,paplay again can recovery

To Reproduce
1.sudo reboot with headset connected
2.open sound settings
3.set Output Device as " Speaker-sof-hda-dsp"
4.set Input Device as "Headset Mono Microphone-sof-hda-dsp" or"Digital Microphone-sof-hda-dsp"
5.paplay wav/48California_Dreaming.wav -vv
6."sudo rtcwake -m mem -s 10" to suspend
7.wait device to wake up
8.repeat step 6~7 2 times

Reproduction Rate
Reproduction Rate >90% issues can be reproduced when repeating suspend and wakeup 3 times.

Expected behavior
Only speaker has sound output

Actual result
Speaker and headset has sound output at the same time

Amixer contents is below,there is no difference between them
amixer_faile.txt
amixer_pass.log

Platform: CML laptop with onboard codec ALC3204 in HDA mode
Firmware: 5f7d4e2 https://github.com/thesofproject/sof/releases/tag/v1.5-rc1
Kernel: stable linux 5.5.9 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.5.9, commit 81b6e04
Topology: file: tools/topology/sof-hda-generic-2ch.tplg same as firmware
UCM2:UCM2:https://github.com/thesofproject/alsa-ucm-conf/tree/master/ucm2/sof-hda-dsp

dmesg0415.log
sof-logger0415.log

[Liviali155]

Issue can be reproduced on sof/dev(commit:73187435)
Issue can be reproduced on 5.5.8 Kernel: [97453d9] (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.5.8)
Issue can be reproduced on 5.6.3 kernel:commit f9fb857

[juimonen]

yeah I can reproduce this. Can't think anything else that this has to be something in quite low level as we have alsamixer headphones muted, but still the sound is going there... so the actual codec and alsa mute are out of sync.

[juimonen]

@mengdonglin @Liviali155 After debugging this I see that when waking up from suspend, snd_hda_codec_realtek is syncing the register 0x21b8000 to value 0x80. Per my debugging this should be the headphone path mute and the value 0x80 should mean muted.

Why this is not muting the actual codec is a mystery to me. I see the same sequence with the forced "rtcwake" call and with just letting the codec go itself to suspend/wake. The difference is that user space pulseaudio doesn't go to its normal "suspend", the process is just frozen (I guess). So when pulseaudio process wakes up it doesn't do any twiddling of alsa parameters. And for some reason the register sync is not enough by itself.

I think we need to ask from realtek some info/clues about this.

[Liviali155]

Issue can be reproduced after revert PR #1983

[juimonen]

@bardliao can you point out this issue for realtek folks also for some comments? I'm little bit lost how to advance with this...

[ClarexZhou]

Error not seen on Lenovo Yoga x1 ALC285 in HDA mode, with 1.4.2 fw. Tried withe 5.5.9 and 5.6.3 kernel.

[bardliao]

@bardliao can you point out this issue for realtek folks also for some comments? I'm little bit lost how to advance with this...

Sent email to @KailangYang.

[juimonen]

@bardliao thank you!

[bardliao]

@ClarexZhou @Liviali155 Can you check if below experiments can mute the headphone when you meet the issue?

1. amixer cset name='Headphone Playback Switch' 1 and amixer cset name='Headphone Playback Switch' 0
2. unplug and plug the headphone.
   Please do the 2 experiment separately.

Thanks