Re: [REGRESSION] Audio popping on ThinkPad X1 Carbon Gen 12 (ALC287) after commit d2e01e0c5e94

[Takashi Iwai <tiwai@suse.de>]

On Tue, 10 Mar 2026 09:24:38 +0100,
Jérémy Bethmont wrote:
> 
> Hi Takashi,
> 
> Thank you for looking into this so quickly.
> 
> As requested, I have attached the output of `alsa-info.sh --no-upload`
> from my machine.
> 
> Please let me know if you have a proposed patch you would like me to
> test. I am happy to build it and verify if it resolves the popping on
> my hardware.

I guess dropping the alc_process_coef_fw(codec, en_coefs) call at
closing would fix your problem while keeping the one at open.
But I'm not sure about any side-effect by that.
Kailang, could you check this?

BTW, when you disable runtime PM, does the pop noise still appears?


thanks,

Takashi

> 
> Best regards,
> Jeremy
> 
> On Tue, 10 Mar 2026 at 13:47, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Tue, 10 Mar 2026 01:01:11 +0100,
> > Jérémy Bethmont wrote:
> > >
> > > Hi Takashi, Kailang,
> > >
> > > I am reporting an audio regression introduced in kernel 6.18.13 on the
> > > Lenovo ThinkPad X1 Carbon Gen 12 (Meteor Lake, Realtek ALC287 codec,
> > > SSID: 0x17aa231e).
> > >
> > > Since this update, the laptop emits a short, noticeable hardware
> > > pop/blip from the speakers exactly when an audio stream closes and the
> > > PCM state suspends. It happens consistently a few seconds after
> > > playback finishes (e.g., after a system notification or terminal
> > > bell).
> > >
> > > I have tracked the regression down to the following commit:
> > > d2e01e0c5e947da0b5005ca89efa82baeb232adc ("ALSA: hda/realtek - fixed
> > > speaker no sound")
> > >
> > > #regzbot introduced: d2e01e0c5e947da0b5005ca89efa82baeb232adc
> > >
> > > Root cause analysis:
> > > The commit modifies the `alc287_alc1318_playback_pcm_hook` function,
> > > adding raw COEF writes to disable/enable AMP silence detection on
> > > HDA_GEN_PCM_ACT_OPEN and HDA_GEN_PCM_ACT_CLOSE.
> > >
> > > Because `alc287_alc1318_playback_pcm_hook` is a shared hook used by
> > > multiple Lenovo ALC287/ALC1318 devices, these unconditional
> > > `WRITE_COEF` instructions are being sent to hardware that does not
> > > need the silence detection fix. On the X1 Carbon Gen 12, executing
> > > `alc_process_coef_fw(codec, en_coefs)` upon stream close triggers an
> > > immediate electrical pop. Monitoring with `pw-mon` confirms the
> > > hardware pop coincides perfectly with the monitor_FR / monitor_FL
> > > ports going idle/suspended.
> > >
> > > Proposed solution:
> > > Could we revert this commit, or alternatively, wrap these specific
> > > silence-detection COEF writes in a targeted `ALC287_FIXUP` quirk
> > > matched via SSID/DMI, rather than executing them globally in the
> > > shared playback hook?
> >
> > Could you give alsa-info.sh output?  Run the script with --no-upload
> > option and attach the output.
> >
> > I guess the bug might not be specific to your device but happening in
> > general with all matching ones.  As a workaround for such a pop noise,
> > we often need to reorder verbs or put some delay between verbs.
> >
> >
> > Takashi
> 
> 
> 
> -- 
> Jérémy Bethmont
>