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@xxxxxxx/
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