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

[Takashi Iwai]

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