Re: [REGRESSION] Speaker pop/chirp on Meteor Lake ALC287 (17aa:231e) -- 6.12.73 to 6.12.85

[Mike Karcic]

Bringing this back with two new data points from the same unit
(ThinkPad X1 Carbon Gen 12, machine type 21KC / 21KCCTO1WW, ALC287,
SSID 17aa:231e, BIOS N3YET85W (1.50)).

1. Windows: I installed Windows 11 on this laptop with Lenovo's Realtek
audio driver (6.0.9788.1, from Lenovo's driver pack) and used it for a
few hours without the chirp ever reproducing. As soon as I switched
back to Fedora/Aurora, it chirped again right away.

2. Linux: on a stock Fedora/Aurora 44 kernel (7.1.8-200.fc44), I wrote
the old en_coefs values once after boot, i.e. these writes to the
vendor widget 0x20 (sent through /dev/snd/hwC0D0; equivalent hda-verb
commands shown):

hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x24
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF  0x0013
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x25
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF  0x0000
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x26
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF  0xc203
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x28
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF  0x0084
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x29
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF  0xb023

After that the chirp no longer occurs. I now run this from a systemd
oneshot service at boot, and the chirp stays away across reboots. I
have not yet checked suspend/resume.

Happy to test anything else.

Thanks,
Mike

Sent with Proton Mail secure email.

On Monday, July 6th, 2026 at 6:58 AM, Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> wrote:

> On 6/5/26 09:14, Takashi Iwai wrote:
> > On Fri, 05 Jun 2026 09:02:29 +0200,
> > Kailang wrote:
> >> Yes, it's the same codec and SSID. It's the same model of machine.
> > Hrm, and still they show different behavior?  That's tough.
> 
> TWIMC: I have this on the list of regressions I track, but seems things
> stalled -- and at the same time it's a tricky situation where fixing
> this regressions would cause another regression. Which is why I'll stop
> tracking this, unless this reminder bringt this thread back to life somehow.
> 
> Ciao, Thorsten
> 
> >> -----Original Message-----
> >> From: Takashi Iwai <tiwai@xxxxxxx>
> >> Sent: Wednesday, June 3, 2026 1:45 AM
> >> To: Kailang <kailang@xxxxxxxxxxx>
> >> Cc: Takashi Iwai <tiwai@xxxxxxx>; Mike Karcic <mikekarcic@xxxxxxxxxxxxxx>; Sean Rhodes <sean@starlabs.systems>; stable@xxxxxxxxxxxxxxx; regressions@xxxxxxxxxxxxxxx; linux-sound@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> >> Subject: Re: [REGRESSION] Speaker pop/chirp on Meteor Lake ALC287 (17aa:231e) -- 6.12.73 to 6.12.85
> >>
> >>
> >> External mail : This email originated from outside the organization. Do not reply, click links, or open attachments unless you recognize the sender and know the content is safe.
> >>
> >>
> >>
> >> On Tue, 02 Jun 2026 08:14:14 +0200,
> >> Kailang wrote:
> >>>
> >>>
> >>> There were the same SSID for two different symptoms.
> >>> But this project was from 2025. This machine maybe didn't in our site.
> >>
> >> Aha, that can explain the difference of the behavior, then.
> >> Do both of them have the same codec ID and SSID, too?
> >>
> >>
> >> Takashi
> >>
> >>>
> >>> -----Original Message-----
> >>> From: Takashi Iwai <tiwai@xxxxxxx>
> >>> Sent: Friday, May 29, 2026 4:20 AM
> >>> To: Mike Karcic <mikekarcic@xxxxxxxxxxxxxx>
> >>> Cc: Kailang <kailang@xxxxxxxxxxx>; Takashi Iwai <tiwai@xxxxxxx>; Sean
> >>> Rhodes <sean@starlabs.systems>; stable@xxxxxxxxxxxxxxx;
> >>> regressions@xxxxxxxxxxxxxxx; linux-sound@xxxxxxxxxxxxxxx;
> >>> linux-kernel@xxxxxxxxxxxxxxx
> >>> Subject: Re: [REGRESSION] Speaker pop/chirp on Meteor Lake ALC287
> >>> (17aa:231e) -- 6.12.73 to 6.12.85
> >>>
> >>>
> >>> External mail : This email originated from outside the organization. Do not reply, click links, or open attachments unless you recognize the sender and know the content is safe.
> >>>
> >>>
> >>>
> >>> On Thu, 28 May 2026 20:27:30 +0200,
> >>> Mike Karcic wrote:
> >>>>
> >>>> Yes, I can confirm the patched kernel is running, and commenting out that line fixes the problem completely.
> >>>>
> >>>> Below is output with the added debug lines as requested:
> >>>>
> >>>> $ uname -r
> >>>> 6.12.90-debug-no-discoefs
> >>>>
> >>>> $ sudo dmesg | grep -i "alc287_alc1318"
> >>>> [  453.823528] snd_hda_codec_realtek ehdaudio0D0:
> >>>> alc287_alc1318_playback_pcm_hook called action=0 [  453.871577]
> >>>> snd_hda_codec_realtek ehdaudio0D0: alc287_alc1318_playback_pcm_hook
> >>>> called action=1 [  459.605379] snd_hda_codec_realtek ehdaudio0D0:
> >>>> alc287_alc1318_playback_pcm_hook called action=2 [  459.605497]
> >>>> snd_hda_codec_realtek ehdaudio0D0: alc287_alc1318_playback_pcm_hook
> >>>> called action=3
> >>>>
> >>>> $ grep -n -A5 -B2 "alc_process_coef_fw.*dis_coefs" sound/pci/hda/patch_realtek.c
> >>>> 7918-           return;
> >>>> 7919-   alc_update_coef_idx(codec, 0x10, 1<<11, 1<<11);
> >>>> 7920:   /* alc_process_coef_fw(codec, dis_coefs); */ /* commented out for testing */
> >>>> 7921-   alc_process_coef_fw(codec, coefs);
> >>>> 7922-   spec->power_hook = alc287_s4_power_gpio3_default;
> >>>> 7923-   spec->gen.pcm_playback_hook = alc287_alc1318_playback_pcm_hook;
> >>>> 7924-}
> >>>
> >>> Hm, then the previous fix doesn't seem working, obviously.
> >>> Kailang, could you check this in your side?
> >>>
> >>> Maybe we should apply the AMP-silence-detection disablement conditionally to certain models?
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>>
> >>>>
> >>>>
> >>>> Sent with Proton Mail secure email.
> >>>>
> >>>> On Thursday, May 28th, 2026 at 10:07 AM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> >>>>
> >>>>> On Thu, 28 May 2026 15:38:54 +0200, Mike Karcic wrote:
> >>>>>>
> >>>>>> I did test 46c862f5419e on 6.12.90. Chirp still present.
> >>>>>>
> >>>>>> I'm also on a ThinkPad X1 Carbon Gen 12 with ALC287 (17aa:231e),
> >>>>>> same as the original reporter. The fix resolved it for them but
> >>>>>> not for me.
> >>>>>>
> >>>>>> Only a full revert of 630fbc6e870e resolves the issue.
> >>>>>>
> >>>>>> Verification on the running kernel:
> >>>>>>
> >>>>>>   $ grep -c "dis_coefs" sound/pci/hda/patch_realtek.c
> >>>>>>   2
> >>>>>>
> >>>>>>   $ grep -c "en_coefs" sound/pci/hda/patch_realtek.c
> >>>>>>   0
> >>>>>>
> >>>>>>   $ sed -n '/alc287_alc1318_playback_pcm_hook/,/^}/p' sound/pci/hda/patch_realtek.c
> >>>>>>   static void alc287_alc1318_playback_pcm_hook(struct hda_pcm_stream *hinfo,
> >>>>>>                                      struct hda_codec *codec,
> >>>>>>                                      struct snd_pcm_substream *substream,
> >>>>>>                                      int action)
> >>>>>>   {
> >>>>>>           switch (action) {
> >>>>>>           case HDA_GEN_PCM_ACT_OPEN:
> >>>>>>                   alc_write_coefex_idx(codec, 0x5a, 0x00, 0x954f);
> >>>>>>                   break;
> >>>>>>           case HDA_GEN_PCM_ACT_CLOSE:
> >>>>>>                   alc_write_coefex_idx(codec, 0x5a, 0x00, 0x554f);
> >>>>>>                   break;
> >>>>>>           }
> >>>>>>   }
> >>>>>>
> >>>>>> Happy to test further patches.
> >>>>>
> >>>>> Just to be sure, could you verify that you've tested really the
> >>>>> patched kernel, e.g. by adding a debug print, etc?
> >>>>> If yes and the problem is seen even with the patch, try to comment out
> >>>>>   alc_process_coef_fw(codec, dis_coefs); and confirm that this
> >>>>> fixes the problem.
> >>>>>
> >>>>>
> >>>>> Takashi
> >>>>>
> >
> 
>