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

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 <[email protected]> 
>> Sent: Wednesday, June 3, 2026 1:45 AM
>> To: Kailang <[email protected]>
>> Cc: Takashi Iwai <[email protected]>; Mike Karcic <[email protected]>; Sean Rhodes <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
>> 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 <[email protected]>
>>> Sent: Friday, May 29, 2026 4:20 AM
>>> To: Mike Karcic <[email protected]>
>>> Cc: Kailang <[email protected]>; Takashi Iwai <[email protected]>; Sean 
>>> Rhodes <[email protected]>; [email protected]; 
>>> [email protected]; [email protected]; 
>>> [email protected]
>>> 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 <[email protected]> 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
>>>>>
>