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

[Takashi Iwai]

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.


Takashi

> 
> -----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
> > > >