Bug 215484 - Headphone output gets unproperly powered down - Mi Notebook Pro 2020 (ALC256)
Summary: Headphone output gets unproperly powered down - Mi Notebook Pro 2020 (ALC256)
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
Depends on:
Reported: 2022-01-11 20:16 UTC by Emanuele Melzi
Modified: 2022-03-30 15:59 UTC (History)
4 users (show)

See Also:
Kernel Version: 5.16.0
Regression: Yes
Bisected commit-id:

alsa-info output with headphones connected (63.28 KB, text/plain)
2022-01-11 20:16 UTC, Emanuele Melzi
bisect.log for the faulty commit (1001 bytes, text/plain)
2022-01-14 15:36 UTC, Emanuele Melzi
proposed fix (706 bytes, patch)
2022-01-18 07:29 UTC, Kai-Heng Feng
Details | Diff
patch v2 (1.61 KB, application/mbox)
2022-03-29 06:20 UTC, Kai-Heng Feng

Description Emanuele Melzi 2022-01-11 20:16:11 UTC
Created attachment 300255 [details]
alsa-info output with headphones connected

With headphones (or an auxiliary jack) plugged in, the audio output is fine when anything is playing, but when that's stopped a loud pop can be heard after some seconds and if the jack is connected to an external amplifier it gets really noisy. 
Everything gets back to normal whenever audio playback is resumed, although with another loud pop at the start.

This has been happening since kernel 5.14.14, whereas 5.14.13 is fine. I suspect it has to do with the ALC256 mute logic implemented in that version (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/sound/pci/hda/patch_realtek.c?id=v5.14.14&id2=v5.14.13) 

OS: Fedora Linux 35
Kernel: 5.16.0-60 Vanilla
Hardware: Xiaomi Mi Notebook Pro Enhanced 2020 (i7 10510U, ALC256)
Comment 1 Takashi Iwai 2022-01-12 09:39:38 UTC
Could you try bisect?
Comment 2 Emanuele Melzi 2022-01-14 15:35:44 UTC
I have tried bisect, and the bad commit seems to be this: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/pci/hda/patch_realtek.c?id=f8d3c17e1c3720a1497b5c5db514a832834610d1

Attaching bisect.log
Comment 3 Emanuele Melzi 2022-01-14 15:36:42 UTC
Created attachment 300267 [details]
bisect.log for the faulty commit
Comment 4 Takashi Iwai 2022-01-14 16:40:45 UTC

I suppose that the function is recovered when you revert the commit?

If yes, which part plays the role? -- there are two chunks in the patch, the first one is about alc_shutup_pins() and another alc256_shutup().
Comment 5 Emanuele Melzi 2022-01-16 16:50:42 UTC
Yes, I have just tried compiling 5.16 deleting manually only the second part of the patch, and that did it! The first part is not a problem. I just deleted the spec->codec_variant != ALC269_TYPE_ALC256 line on the if.
Comment 6 Takashi Iwai 2022-01-17 09:03:29 UTC
Thanks for quick testing.

Kailang, Kai-Heng, could you guys check this regression?
It seems that the COEF 0x46 change is still required on some ALC256 devices.
Comment 7 Kailiang Yang 2022-01-18 06:37:42 UTC
But set this COEF 0x46, It will lose headset Mic on booted with plugged Headset on some machine.
This was Hui Wang patched.

It will show this symptom on runtime suspend.
Comment 8 Kai-Heng Feng 2022-01-18 06:53:21 UTC
I tested on the originally affected machine which equips ALC236, reverting the patch and adding "codec->core.vendor_id != 0x10ec0236" and MIC recording still works fine.

Kailiang, do you think that also works for you?
Comment 9 Kailiang Yang 2022-01-18 07:15:44 UTC
I think it would be reverted the patch.
Then if the platform with lose headset Mic, 
Please add the quirk with function alc_combo_jack_hp_jd_restart();
Comment 10 Kai-Heng Feng 2022-01-18 07:29:36 UTC
Created attachment 300285 [details]
proposed fix
Comment 11 Kai-Heng Feng 2022-01-18 07:31:28 UTC

With the patch applied, the originally affected system can still detect headset MIC.

Can you please elaborate what you meant on "lose headset MIC"?
Comment 12 Kailiang Yang 2022-01-18 08:20:52 UTC
Hi Kai Heng,

Some platforms meet set COEF 0x46 will lose headset Mic on Booted with plugged Headset.
If it had this symptom, please add a quirk with the function will fix it.
Comment 13 Kai-Heng Feng 2022-01-18 14:39:09 UTC
Commit "ALSA: hda/realtek - ALC236 headset MIC recording issue" solved an issue that first few seconds of recording is missing. So if we change it to 'vendor_id != 0x10ec0257 && vendor_id != 0x10ec0236', the commit can still solve the issue for me and also fix the regression for this bug.

IIUC what you meant is that my proposed patch may introduce another kind of regression, which can be fixed by using alc_combo_jack_hp_jd_restart()?
Comment 14 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-02-16 08:38:23 UTC
What's the status here? Was the issue resolved or did it fall through the cracks?
Comment 15 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-03-14 12:45:57 UTC
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #14)
> What's the status here? Was the issue resolved or did it fall through the
> cracks?

That was four week ago, no answer from the developers. That's not how regressions should be handled. :-/ Or was the problem fixed meanwhile? Emanuele, is this problem still present in 5.15.y or 5.16.y?
Comment 16 Emanuele Melzi 2022-03-19 18:19:14 UTC
Yes, I am currently on 5.16.12 and the problem is still present
Comment 17 Kai-Heng Feng 2022-03-21 07:37:17 UTC
(In reply to Emanuele Melzi from comment #16)
> Yes, I am currently on 5.16.12 and the problem is still present

Can you please give the diff in comment #10 a try? Thanks!
Comment 18 Emanuele Melzi 2022-03-26 18:59:32 UTC
I just tried the patch on comment 10 on 5.17 and it works!
Comment 19 Kai-Heng Feng 2022-03-29 06:20:38 UTC
Created attachment 300636 [details]
patch v2

I made a stupid mistake in the patch, please test v2 patch here, thanks!
Comment 20 Emanuele Melzi 2022-03-30 15:59:36 UTC
v2 patch works too!

Note You need to log in before you can comment on or make changes to this bug.