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

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

[Mike Karcic]

Speaker pop/chirp regression on a Lenovo ThinkPad with Meteor Lake and
Realtek ALC287 (subsystem ID 17aa:231e). The chirp occurs on speaker
power state transitions when audio starts or stops. It is not present
on kernel 6.12.73 and is present on 6.12.85. A desktop with ALC897
(subsystem ID 1f660202) on kernel 6.19.14 is unaffected, so this is
codec/fixup-specific.

Tested on the same LMDE (Debian 13) installation with multiple kernels
selectable from GRUB. All userspace, firmware, and configuration are
identical between tests. Cold boot between kernel switches is required,
as warm reboot can carry codec register state forward. The kernel is
not tainted on any tested version.

Bisection results (Debian package versions):
  6.12.48  -- no chirp
  6.12.73  -- no chirp
  6.12.85  -- chirp present
  6.12.86  -- chirp present
  6.12.90  -- chirp present

Also broken: 6.19.14-101.fc44.x86_64 (Fedora/Aurora 44)

The regression window (6.12.73 to 6.12.85) includes two commits
targeting speaker pop on the Star Labs StarFighter (ALC233, SSID
7017:2014) that touch patch_realtek.c:

  1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter")
  Fixes commit ("ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter")

These are quirk-gated to SSID 7017:2014 and should not run on
17aa:231e, but they are the most prominent sound changes in the
regression window. The actual culprit may be a different commit
in the 6.12.74-6.12.85 range. I was unable to narrow further as
Debian does not publish intermediate point-release packages.

I can build and test vanilla kernels for a proper bisection if
guided, and I can test proposed fixes.

Hardware:
  Lenovo ThinkPad, Meteor Lake
  Codec: Realtek ALC287
  Subsystem ID: 17aa:231e
  PCI: 0000:00:1f.3
  Machine driver: skl_hda_dsp_generic
  Codec fixup: "ALC287: picked fixup for PCI SSID 17aa:231e"

Unaffected hardware (same 6.19.14 kernel, no chirp):
  Desktop, Realtek ALC897, Subsystem ID: 1f660202

Controlled variables (identical across all tested 6.12 kernels):
  SOF firmware: 2.12.0.1 (firmware-sof-signed 2025.01-1)
  Topology: intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
  Topology ABI: 3:29:1 (Kernel ABI: 3:23:1 on all tested)
  ALSA UCM: alsa-ucm-conf 1.2.14-1
  PipeWire: 1.4.2, WirePlumber: 0.5.8
  power_save: 10, hda_model: (null)
  Desktop: KDE Plasma 6 (Wayland)

Eliminated causes:
  - Topology files in sof-ipc4-tplg/ and sof-ace-tplg/ are
    byte-identical (confirmed via binary diff). Path irrelevant.
  - SOF firmware version (same 2.12.0.1 on all tested kernels).
  - Topology ABI mismatch (3:29:1 vs 3:23:1 present on working
    kernel too).
  - power_save (10 on all kernels).
  - PipeWire/WirePlumber (identical versions on all kernels).
  - Desktop environment (KDE on all; a KDE install triggered a
    kernel update which was the actual cause of the regression
    appearing).

dmesg (6.12.48, working):
  sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
  sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.12.0.1
  sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
  snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
  snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker

dmesg (6.19.14, affected):
  sof-audio-pci-intel-mtl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
  sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380
  sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
  sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
  sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
  sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
  sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
  snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
  snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker

Note: The kernel is not tainted on any tested version.

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

[Sean Rhodes]

What about 630fbc6e870e? If so, 46c862f5419e looks relevant.

On Wed, 27 May 2026 at 15:25, Mike Karcic <mikekarcic@protonmail.com> wrote:
>
> Speaker pop/chirp regression on a Lenovo ThinkPad with Meteor Lake and
> Realtek ALC287 (subsystem ID 17aa:231e). The chirp occurs on speaker
> power state transitions when audio starts or stops. It is not present
> on kernel 6.12.73 and is present on 6.12.85. A desktop with ALC897
> (subsystem ID 1f660202) on kernel 6.19.14 is unaffected, so this is
> codec/fixup-specific.
>
> Tested on the same LMDE (Debian 13) installation with multiple kernels
> selectable from GRUB. All userspace, firmware, and configuration are
> identical between tests. Cold boot between kernel switches is required,
> as warm reboot can carry codec register state forward. The kernel is
> not tainted on any tested version.
>
> Bisection results (Debian package versions):
>   6.12.48  -- no chirp
>   6.12.73  -- no chirp
>   6.12.85  -- chirp present
>   6.12.86  -- chirp present
>   6.12.90  -- chirp present
>
> Also broken: 6.19.14-101.fc44.x86_64 (Fedora/Aurora 44)
>
> The regression window (6.12.73 to 6.12.85) includes two commits
> targeting speaker pop on the Star Labs StarFighter (ALC233, SSID
> 7017:2014) that touch patch_realtek.c:
>
>   1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter")
>   Fixes commit ("ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter")
>
> These are quirk-gated to SSID 7017:2014 and should not run on
> 17aa:231e, but they are the most prominent sound changes in the
> regression window. The actual culprit may be a different commit
> in the 6.12.74-6.12.85 range. I was unable to narrow further as
> Debian does not publish intermediate point-release packages.
>
> I can build and test vanilla kernels for a proper bisection if
> guided, and I can test proposed fixes.
>
> Hardware:
>   Lenovo ThinkPad, Meteor Lake
>   Codec: Realtek ALC287
>   Subsystem ID: 17aa:231e
>   PCI: 0000:00:1f.3
>   Machine driver: skl_hda_dsp_generic
>   Codec fixup: "ALC287: picked fixup for PCI SSID 17aa:231e"
>
> Unaffected hardware (same 6.19.14 kernel, no chirp):
>   Desktop, Realtek ALC897, Subsystem ID: 1f660202
>
> Controlled variables (identical across all tested 6.12 kernels):
>   SOF firmware: 2.12.0.1 (firmware-sof-signed 2025.01-1)
>   Topology: intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
>   Topology ABI: 3:29:1 (Kernel ABI: 3:23:1 on all tested)
>   ALSA UCM: alsa-ucm-conf 1.2.14-1
>   PipeWire: 1.4.2, WirePlumber: 0.5.8
>   power_save: 10, hda_model: (null)
>   Desktop: KDE Plasma 6 (Wayland)
>
> Eliminated causes:
>   - Topology files in sof-ipc4-tplg/ and sof-ace-tplg/ are
>     byte-identical (confirmed via binary diff). Path irrelevant.
>   - SOF firmware version (same 2.12.0.1 on all tested kernels).
>   - Topology ABI mismatch (3:29:1 vs 3:23:1 present on working
>     kernel too).
>   - power_save (10 on all kernels).
>   - PipeWire/WirePlumber (identical versions on all kernels).
>   - Desktop environment (KDE on all; a KDE install triggered a
>     kernel update which was the actual cause of the regression
>     appearing).
>
> dmesg (6.12.48, working):
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
>   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
>   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
>   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.12.0.1
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
>   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
>   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
>
> dmesg (6.19.14, affected):
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
>   sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380
>   sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
>   sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
>   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
>   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
>   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
>   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
>   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
>   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
>
> Note: The kernel is not tainted on any tested version.

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

[Mike Karcic]

I tested both setups on top of Debian's 6.12.90 source tree. 

1. I applied the 46c862f5419e patch, but the chirp was still there on every audio transition.
2. I did a full revert of 630fbc6e870e, and the chirp is completely gone.

My hardware is a Lenovo ThinkPad (Meteor Lake), ALC287, subsystem 17aa:231e.



Sent with Proton Mail secure email.

On Wednesday, May 27th, 2026 at 3:44 PM, Sean Rhodes <sean@starlabs.systems> wrote:

> What about 630fbc6e870e? If so, 46c862f5419e looks relevant.
> 
> On Wed, 27 May 2026 at 15:25, Mike Karcic <mikekarcic@protonmail.com> wrote:
> >
> > Speaker pop/chirp regression on a Lenovo ThinkPad with Meteor Lake and
> > Realtek ALC287 (subsystem ID 17aa:231e). The chirp occurs on speaker
> > power state transitions when audio starts or stops. It is not present
> > on kernel 6.12.73 and is present on 6.12.85. A desktop with ALC897
> > (subsystem ID 1f660202) on kernel 6.19.14 is unaffected, so this is
> > codec/fixup-specific.
> >
> > Tested on the same LMDE (Debian 13) installation with multiple kernels
> > selectable from GRUB. All userspace, firmware, and configuration are
> > identical between tests. Cold boot between kernel switches is required,
> > as warm reboot can carry codec register state forward. The kernel is
> > not tainted on any tested version.
> >
> > Bisection results (Debian package versions):
> >   6.12.48  -- no chirp
> >   6.12.73  -- no chirp
> >   6.12.85  -- chirp present
> >   6.12.86  -- chirp present
> >   6.12.90  -- chirp present
> >
> > Also broken: 6.19.14-101.fc44.x86_64 (Fedora/Aurora 44)
> >
> > The regression window (6.12.73 to 6.12.85) includes two commits
> > targeting speaker pop on the Star Labs StarFighter (ALC233, SSID
> > 7017:2014) that touch patch_realtek.c:
> >
> >   1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter")
> >   Fixes commit ("ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter")
> >
> > These are quirk-gated to SSID 7017:2014 and should not run on
> > 17aa:231e, but they are the most prominent sound changes in the
> > regression window. The actual culprit may be a different commit
> > in the 6.12.74-6.12.85 range. I was unable to narrow further as
> > Debian does not publish intermediate point-release packages.
> >
> > I can build and test vanilla kernels for a proper bisection if
> > guided, and I can test proposed fixes.
> >
> > Hardware:
> >   Lenovo ThinkPad, Meteor Lake
> >   Codec: Realtek ALC287
> >   Subsystem ID: 17aa:231e
> >   PCI: 0000:00:1f.3
> >   Machine driver: skl_hda_dsp_generic
> >   Codec fixup: "ALC287: picked fixup for PCI SSID 17aa:231e"
> >
> > Unaffected hardware (same 6.19.14 kernel, no chirp):
> >   Desktop, Realtek ALC897, Subsystem ID: 1f660202
> >
> > Controlled variables (identical across all tested 6.12 kernels):
> >   SOF firmware: 2.12.0.1 (firmware-sof-signed 2025.01-1)
> >   Topology: intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
> >   Topology ABI: 3:29:1 (Kernel ABI: 3:23:1 on all tested)
> >   ALSA UCM: alsa-ucm-conf 1.2.14-1
> >   PipeWire: 1.4.2, WirePlumber: 0.5.8
> >   power_save: 10, hda_model: (null)
> >   Desktop: KDE Plasma 6 (Wayland)
> >
> > Eliminated causes:
> >   - Topology files in sof-ipc4-tplg/ and sof-ace-tplg/ are
> >     byte-identical (confirmed via binary diff). Path irrelevant.
> >   - SOF firmware version (same 2.12.0.1 on all tested kernels).
> >   - Topology ABI mismatch (3:29:1 vs 3:23:1 present on working
> >     kernel too).
> >   - power_save (10 on all kernels).
> >   - PipeWire/WirePlumber (identical versions on all kernels).
> >   - Desktop environment (KDE on all; a KDE install triggered a
> >     kernel update which was the actual cause of the regression
> >     appearing).
> >
> > dmesg (6.12.48, working):
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
> >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
> >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
> >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.12.0.1
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
> >   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
> >   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
> >
> > dmesg (6.19.14, affected):
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
> >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
> >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
> >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
> >   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
> >   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
> >   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
> >
> > Note: The kernel is not tainted on any tested version.
>

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

[Takashi Iwai]

On Thu, 28 May 2026 01:18:31 +0200,
Mike Karcic wrote:
> 
> I tested both setups on top of Debian's 6.12.90 source tree. 
> 
> 1. I applied the 46c862f5419e patch, but the chirp was still there on every audio transition.
> 2. I did a full revert of 630fbc6e870e, and the chirp is completely gone.

There is a follow-up fix in the upstream, try to apply the commit
46c862f5419e ("ALSA: hda/realtek - fixed speaker no sound update").


thanks,

Takashi


> 
> My hardware is a Lenovo ThinkPad (Meteor Lake), ALC287, subsystem 17aa:231e.
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> On Wednesday, May 27th, 2026 at 3:44 PM, Sean Rhodes <sean@starlabs.systems> wrote:
> 
> > What about 630fbc6e870e? If so, 46c862f5419e looks relevant.
> > 
> > On Wed, 27 May 2026 at 15:25, Mike Karcic <mikekarcic@protonmail.com> wrote:
> > >
> > > Speaker pop/chirp regression on a Lenovo ThinkPad with Meteor Lake and
> > > Realtek ALC287 (subsystem ID 17aa:231e). The chirp occurs on speaker
> > > power state transitions when audio starts or stops. It is not present
> > > on kernel 6.12.73 and is present on 6.12.85. A desktop with ALC897
> > > (subsystem ID 1f660202) on kernel 6.19.14 is unaffected, so this is
> > > codec/fixup-specific.
> > >
> > > Tested on the same LMDE (Debian 13) installation with multiple kernels
> > > selectable from GRUB. All userspace, firmware, and configuration are
> > > identical between tests. Cold boot between kernel switches is required,
> > > as warm reboot can carry codec register state forward. The kernel is
> > > not tainted on any tested version.
> > >
> > > Bisection results (Debian package versions):
> > >   6.12.48  -- no chirp
> > >   6.12.73  -- no chirp
> > >   6.12.85  -- chirp present
> > >   6.12.86  -- chirp present
> > >   6.12.90  -- chirp present
> > >
> > > Also broken: 6.19.14-101.fc44.x86_64 (Fedora/Aurora 44)
> > >
> > > The regression window (6.12.73 to 6.12.85) includes two commits
> > > targeting speaker pop on the Star Labs StarFighter (ALC233, SSID
> > > 7017:2014) that touch patch_realtek.c:
> > >
> > >   1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter")
> > >   Fixes commit ("ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter")
> > >
> > > These are quirk-gated to SSID 7017:2014 and should not run on
> > > 17aa:231e, but they are the most prominent sound changes in the
> > > regression window. The actual culprit may be a different commit
> > > in the 6.12.74-6.12.85 range. I was unable to narrow further as
> > > Debian does not publish intermediate point-release packages.
> > >
> > > I can build and test vanilla kernels for a proper bisection if
> > > guided, and I can test proposed fixes.
> > >
> > > Hardware:
> > >   Lenovo ThinkPad, Meteor Lake
> > >   Codec: Realtek ALC287
> > >   Subsystem ID: 17aa:231e
> > >   PCI: 0000:00:1f.3
> > >   Machine driver: skl_hda_dsp_generic
> > >   Codec fixup: "ALC287: picked fixup for PCI SSID 17aa:231e"
> > >
> > > Unaffected hardware (same 6.19.14 kernel, no chirp):
> > >   Desktop, Realtek ALC897, Subsystem ID: 1f660202
> > >
> > > Controlled variables (identical across all tested 6.12 kernels):
> > >   SOF firmware: 2.12.0.1 (firmware-sof-signed 2025.01-1)
> > >   Topology: intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
> > >   Topology ABI: 3:29:1 (Kernel ABI: 3:23:1 on all tested)
> > >   ALSA UCM: alsa-ucm-conf 1.2.14-1
> > >   PipeWire: 1.4.2, WirePlumber: 0.5.8
> > >   power_save: 10, hda_model: (null)
> > >   Desktop: KDE Plasma 6 (Wayland)
> > >
> > > Eliminated causes:
> > >   - Topology files in sof-ipc4-tplg/ and sof-ace-tplg/ are
> > >     byte-identical (confirmed via binary diff). Path irrelevant.
> > >   - SOF firmware version (same 2.12.0.1 on all tested kernels).
> > >   - Topology ABI mismatch (3:29:1 vs 3:23:1 present on working
> > >     kernel too).
> > >   - power_save (10 on all kernels).
> > >   - PipeWire/WirePlumber (identical versions on all kernels).
> > >   - Desktop environment (KDE on all; a KDE install triggered a
> > >     kernel update which was the actual cause of the regression
> > >     appearing).
> > >
> > > dmesg (6.12.48, working):
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.12.0.1
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
> > >   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
> > >   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
> > >
> > > dmesg (6.19.14, affected):
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
> > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
> > >   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
> > >   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
> > >
> > > Note: The kernel is not tainted on any tested version.
> >

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

[Mike Karcic]

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.



Sent with Proton Mail secure email.

On Thursday, May 28th, 2026 at 2:08 AM, Takashi Iwai <tiwai@suse.de> wrote:

> On Thu, 28 May 2026 01:18:31 +0200,
> Mike Karcic wrote:
> >
> > I tested both setups on top of Debian's 6.12.90 source tree.
> >
> > 1. I applied the 46c862f5419e patch, but the chirp was still there on every audio transition.
> > 2. I did a full revert of 630fbc6e870e, and the chirp is completely gone.
> 
> There is a follow-up fix in the upstream, try to apply the commit
> 46c862f5419e ("ALSA: hda/realtek - fixed speaker no sound update").
> 
> 
> thanks,
> 
> Takashi
> 
> 
> >
> > My hardware is a Lenovo ThinkPad (Meteor Lake), ALC287, subsystem 17aa:231e.
> >
> >
> >
> > Sent with Proton Mail secure email.
> >
> > On Wednesday, May 27th, 2026 at 3:44 PM, Sean Rhodes <sean@starlabs.systems> wrote:
> >
> > > What about 630fbc6e870e? If so, 46c862f5419e looks relevant.
> > >
> > > On Wed, 27 May 2026 at 15:25, Mike Karcic <mikekarcic@protonmail.com> wrote:
> > > >
> > > > Speaker pop/chirp regression on a Lenovo ThinkPad with Meteor Lake and
> > > > Realtek ALC287 (subsystem ID 17aa:231e). The chirp occurs on speaker
> > > > power state transitions when audio starts or stops. It is not present
> > > > on kernel 6.12.73 and is present on 6.12.85. A desktop with ALC897
> > > > (subsystem ID 1f660202) on kernel 6.19.14 is unaffected, so this is
> > > > codec/fixup-specific.
> > > >
> > > > Tested on the same LMDE (Debian 13) installation with multiple kernels
> > > > selectable from GRUB. All userspace, firmware, and configuration are
> > > > identical between tests. Cold boot between kernel switches is required,
> > > > as warm reboot can carry codec register state forward. The kernel is
> > > > not tainted on any tested version.
> > > >
> > > > Bisection results (Debian package versions):
> > > >   6.12.48  -- no chirp
> > > >   6.12.73  -- no chirp
> > > >   6.12.85  -- chirp present
> > > >   6.12.86  -- chirp present
> > > >   6.12.90  -- chirp present
> > > >
> > > > Also broken: 6.19.14-101.fc44.x86_64 (Fedora/Aurora 44)
> > > >
> > > > The regression window (6.12.73 to 6.12.85) includes two commits
> > > > targeting speaker pop on the Star Labs StarFighter (ALC233, SSID
> > > > 7017:2014) that touch patch_realtek.c:
> > > >
> > > >   1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter")
> > > >   Fixes commit ("ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter")
> > > >
> > > > These are quirk-gated to SSID 7017:2014 and should not run on
> > > > 17aa:231e, but they are the most prominent sound changes in the
> > > > regression window. The actual culprit may be a different commit
> > > > in the 6.12.74-6.12.85 range. I was unable to narrow further as
> > > > Debian does not publish intermediate point-release packages.
> > > >
> > > > I can build and test vanilla kernels for a proper bisection if
> > > > guided, and I can test proposed fixes.
> > > >
> > > > Hardware:
> > > >   Lenovo ThinkPad, Meteor Lake
> > > >   Codec: Realtek ALC287
> > > >   Subsystem ID: 17aa:231e
> > > >   PCI: 0000:00:1f.3
> > > >   Machine driver: skl_hda_dsp_generic
> > > >   Codec fixup: "ALC287: picked fixup for PCI SSID 17aa:231e"
> > > >
> > > > Unaffected hardware (same 6.19.14 kernel, no chirp):
> > > >   Desktop, Realtek ALC897, Subsystem ID: 1f660202
> > > >
> > > > Controlled variables (identical across all tested 6.12 kernels):
> > > >   SOF firmware: 2.12.0.1 (firmware-sof-signed 2025.01-1)
> > > >   Topology: intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
> > > >   Topology ABI: 3:29:1 (Kernel ABI: 3:23:1 on all tested)
> > > >   ALSA UCM: alsa-ucm-conf 1.2.14-1
> > > >   PipeWire: 1.4.2, WirePlumber: 0.5.8
> > > >   power_save: 10, hda_model: (null)
> > > >   Desktop: KDE Plasma 6 (Wayland)
> > > >
> > > > Eliminated causes:
> > > >   - Topology files in sof-ipc4-tplg/ and sof-ace-tplg/ are
> > > >     byte-identical (confirmed via binary diff). Path irrelevant.
> > > >   - SOF firmware version (same 2.12.0.1 on all tested kernels).
> > > >   - Topology ABI mismatch (3:29:1 vs 3:23:1 present on working
> > > >     kernel too).
> > > >   - power_save (10 on all kernels).
> > > >   - PipeWire/WirePlumber (identical versions on all kernels).
> > > >   - Desktop environment (KDE on all; a KDE install triggered a
> > > >     kernel update which was the actual cause of the regression
> > > >     appearing).
> > > >
> > > > dmesg (6.12.48, working):
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.12.0.1
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
> > > >   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
> > > >   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
> > > >
> > > > dmesg (6.19.14, affected):
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/mtl/sof-mtl.ri
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/mtl
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
> > > >   sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
> > > >   snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
> > > >   snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
> > > >
> > > > Note: The kernel is not tainted on any tested version.
> > >
>

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

[Takashi Iwai]

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

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

[Mike Karcic]

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



Sent with Proton Mail secure email.

On Thursday, May 28th, 2026 at 10:07 AM, Takashi Iwai <tiwai@suse.de> 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
>

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

[Takashi Iwai]

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@suse.de> 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
> >

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

[Kailang]

There were the same SSID for two different symptoms.
But this project was from 2025. This machine maybe didn't in our site.

-----Original Message-----
From: Takashi Iwai <tiwai@suse.de> 
Sent: Friday, May 29, 2026 4:20 AM
To: Mike Karcic <mikekarcic@protonmail.com>
Cc: Kailang <kailang@realtek.com>; Takashi Iwai <tiwai@suse.de>; Sean Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; regressions@lists.linux.dev; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org
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@suse.de> 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
> >

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@suse.de> 
> Sent: Friday, May 29, 2026 4:20 AM
> To: Mike Karcic <mikekarcic@protonmail.com>
> Cc: Kailang <kailang@realtek.com>; Takashi Iwai <tiwai@suse.de>; Sean Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; regressions@lists.linux.dev; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org
> 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@suse.de> 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
> > >

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

[Kailang]

Yes, it's the same codec and SSID. It's the same model of machine.

-----Original Message-----
From: Takashi Iwai <tiwai@suse.de> 
Sent: Wednesday, June 3, 2026 1:45 AM
To: Kailang <kailang@realtek.com>
Cc: Takashi Iwai <tiwai@suse.de>; Mike Karcic <mikekarcic@protonmail.com>; Sean Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; regressions@lists.linux.dev; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org
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@suse.de>
> Sent: Friday, May 29, 2026 4:20 AM
> To: Mike Karcic <mikekarcic@protonmail.com>
> Cc: Kailang <kailang@realtek.com>; Takashi Iwai <tiwai@suse.de>; Sean 
> Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; 
> regressions@lists.linux.dev; linux-sound@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> 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@suse.de> 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
> > >

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@suse.de> 
> Sent: Wednesday, June 3, 2026 1:45 AM
> To: Kailang <kailang@realtek.com>
> Cc: Takashi Iwai <tiwai@suse.de>; Mike Karcic <mikekarcic@protonmail.com>; Sean Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; regressions@lists.linux.dev; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org
> 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@suse.de>
> > Sent: Friday, May 29, 2026 4:20 AM
> > To: Mike Karcic <mikekarcic@protonmail.com>
> > Cc: Kailang <kailang@realtek.com>; Takashi Iwai <tiwai@suse.de>; Sean 
> > Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; 
> > regressions@lists.linux.dev; linux-sound@vger.kernel.org; 
> > linux-kernel@vger.kernel.org
> > 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@suse.de> 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
> > > >

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

[Thorsten Leemhuis]

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@suse.de> 
>> Sent: Wednesday, June 3, 2026 1:45 AM
>> To: Kailang <kailang@realtek.com>
>> Cc: Takashi Iwai <tiwai@suse.de>; Mike Karcic <mikekarcic@protonmail.com>; Sean Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; regressions@lists.linux.dev; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org
>> 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@suse.de>
>>> Sent: Friday, May 29, 2026 4:20 AM
>>> To: Mike Karcic <mikekarcic@protonmail.com>
>>> Cc: Kailang <kailang@realtek.com>; Takashi Iwai <tiwai@suse.de>; Sean 
>>> Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; 
>>> regressions@lists.linux.dev; linux-sound@vger.kernel.org; 
>>> linux-kernel@vger.kernel.org
>>> 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@suse.de> 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
>>>>>
> 

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@leemhuis.info> 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@suse.de>
> >> Sent: Wednesday, June 3, 2026 1:45 AM
> >> To: Kailang <kailang@realtek.com>
> >> Cc: Takashi Iwai <tiwai@suse.de>; Mike Karcic <mikekarcic@protonmail.com>; Sean Rhodes <sean@starlabs.systems>; stable@vger.kernel.org; regressions@lists.linux.dev; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org
> >> 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@suse.de>
> >>> Sent: Friday, May 29, 2026 4:20 AM
> >>> To: Mike Karcic <mikekarcic@protonmail.com>
> >>> Cc: Kailang <kailang@realtek.com>; Takashi Iwai <tiwai@suse.de>; Sean
> >>> Rhodes <sean@starlabs.systems>; stable@vger.kernel.org;
> >>> regressions@lists.linux.dev; linux-sound@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org
> >>> 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@suse.de> 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
> >>>>>
> >
> 
>

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

[Jan Fabian]

(Reply to https://lore.kernel.org/all/87jysdv4qg.wl-tiwai@suse.de/
sent from webmail, so it may not thread automatically.)

Hi Takashi, Kailang,

Another data point from an X1 Carbon Gen 12 with the same codec and
SSID, which behaves like Mike's: the pop is still there with
46c862f5419e. Turning AMP silence detection back on at runtime removes
it, with no kernel rebuild.

Hardware: ThinkPad X1 Carbon Gen 12 (21KC004TGE), BIOS N3YET86W (1.51),
Core Ultra 7 155U. ALC287, vendor 0x10ec0287, subsystem 0x17aa231e,
revision 0x100002.

Software: Ubuntu 26.04, kernel 7.0.0-42-generic (based on 7.0.14), SOF
firmware 2.14.1.1 with sof-hda-generic-2ch.tplg, PipeWire 1.6.2,
WirePlumber 0.5.13.

I checked the compiled module to confirm 46c862f5419e is in effect:
alc287_alc1318_playback_pcm_hook only calls alc_write_coefex_idx, and
alc287_fixup_lenovo_thinkpad_with_alc1318 calls alc_process_coef_fw
twice. So dis_coefs runs once at probe, and en_coefs isn't present.

Symptom: a pop about 5 s after any sound. The sink goes from idle to
suspended exactly 5 s after playback ends, matching WirePlumber's
default timeout. Setting session.suspend-timeout-seconds = 0 stops the
pop, but costs roughly 1-2 W at idle on battery (about 4.4 W against
2.4 W), so it isn't a good workaround here.

Runtime test, writing the old en_coefs values:

  for p in "0x24 0x0013" "0x25 0x0000" "0x26 0xC203" \
           "0x28 0x0084" "0x29 0xb023"; do
    set -- $p
    hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX $1
    hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF $2
  done

Results, by ear, on one boot:

- Before the write: a pop about 5 s after a bell.
- After the write: no pop after two bells, with the sink still
  suspending normally.
- The 630fbc6e870e scenario: a 13 s all-zero stream from one pw-play,
  with three bells from a second pw-play starting 7 s in. All three
  were audible, with no pop afterwards. That was one run, so it says
  little about the original no-sound bug.
- The write also works with the sink and codec runtime-suspended: no
  pop after a bell in a later run.

Not tested yet: whether the setting survives system suspend or
hibernate.

Since Kailang confirmed the same SSID shows different behaviour, is
there something I can read from this machine that would separate the
two groups, such as an amp revision? I'm also happy to test a patch.
From a quick look, master still has the probe-time dis_coefs call as
of late October.

Thanks,
JF

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

[Mike Karcic]

Speaker pop/chirp regression on a Lenovo ThinkPad with Meteor Lake and
Realtek ALC287 (subsystem ID 17aa:231e). The chirp occurs on speaker
power state transitions when audio starts or stops. It is not present
on kernel 6.12.73 and is present on 6.12.85. A desktop with ALC897
(subsystem ID 1f660202) on kernel 6.19.14 is unaffected, so this is
codec/fixup-specific.

Tested on the same LMDE (Debian 13) installation with multiple kernels
selectable from GRUB. All userspace, firmware, and configuration are
identical between tests. Cold boot between kernel switches is required,
as warm reboot can carry codec register state forward. The kernel is
not tainted on any tested version.

Bisection results (Debian package versions):
  6.12.48  -- no chirp
  6.12.73  -- no chirp
  6.12.85  -- chirp present
  6.12.86  -- chirp present
  6.12.90  -- chirp present

Also broken: 6.19.14-101.fc44.x86_64 (Fedora/Aurora 44)

The regression window (6.12.73 to 6.12.85) includes two commits
targeting speaker pop on the Star Labs StarFighter (ALC233, SSID
7017:2014) that touch patch_realtek.c:

  1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter")
  Fixes commit ("ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter")

These are quirk-gated to SSID 7017:2014 and should not run on
17aa:231e, but they are the most prominent sound changes in the
regression window. The actual culprit may be a different commit
in the 6.12.74-6.12.85 range. I was unable to narrow further as
Debian does not publish intermediate point-release packages.

I can build and test vanilla kernels for a proper bisection if
guided, and I can test proposed fixes.

Hardware:
  Lenovo ThinkPad, Meteor Lake
  Codec: Realtek ALC287
  Subsystem ID: 17aa:231e
  PCI: 0000:00:1f.3
  Machine driver: skl_hda_dsp_generic
  Codec fixup: "ALC287: picked fixup for PCI SSID 17aa:231e"

Unaffected hardware (same 6.19.14 kernel, no chirp):
  Desktop, Realtek ALC897, Subsystem ID: 1f660202

Controlled variables (identical across all tested 6.12 kernels):
  SOF firmware: 2.12.0.1 (firmware-sof-signed 2025.01-1)
  Topology: intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
  Topology ABI: 3:29:1 (Kernel ABI: 3:23:1 on all tested)
  ALSA UCM: alsa-ucm-conf 1.2.14-1
  PipeWire: 1.4.2, WirePlumber: 0.5.8
  power_save: 10, hda_model: (null)
  Desktop: KDE Plasma 6 (Wayland)

Eliminated causes:
  - Topology files in sof-ipc4-tplg/ and sof-ace-tplg/ are
    byte-identical (confirmed via binary diff). Path irrelevant.
  - SOF firmware version (same 2.12.0.1 on all tested kernels).
  - Topology ABI mismatch (3:29:1 vs 3:23:1 present on working
    kernel too).
  - power_save (10 on all kernels).
  - PipeWire/WirePlumber (identical versions on all kernels).
  - Desktop environment (KDE on all; a KDE install triggered a
    kernel update which was the actual cause of the regression
    appearing).

dmesg (6.12.48, working):
  sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:
intel/sof-ipc4/mtl/sof-mtl.ri
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path:
intel/sof-ipc4-lib/mtl
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:
intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
  sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.12.0.1
  sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
  snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
  snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1
(0x17/0x0/0x0/0x0/0x0) type:speaker

dmesg (6.19.14, affected):
  sof-audio-pci-intel-mtl 0000:00:1f.3: Digital mics found on Skylake+
platform, using SOF driver
  sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI
class/subclass/prog-if 0x040380
  sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
  sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver
skl_hda_dsp_generic now
  sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware file:
intel/sof-ipc4/mtl/sof-mtl.ri
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Firmware lib path:
intel/sof-ipc4-lib/mtl
  sof-audio-pci-intel-mtl 0000:00:1f.3:  Topology file:
intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
  sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
  sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
  snd_hda_codec_alc269 ehdaudio0D0: ALC287: picked fixup for PCI SSID 17aa:231e
  snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC287: line_outs=1
(0x17/0x0/0x0/0x0/0x0) type:speaker

Note: The kernel is not tainted on any tested version.

-- 
Mike