[ADL][ALC274] Intermittent: combo-jack headphone output silent + constant noise; cleared only by full power-off, not warm reboot — Razer Blade 15 (2022) RZ09-0421
I've been experiencing a weird issue, very rarely when I boot up my laptop I get some kind of interference noise when I plug my headset with a mic into the 3.5 mm jack. The following is a bug report created with Claude Code after I've used it to try to fix the issue:
Describe the bug
On a subset of boots, the analog headphone output is dead: plugging headphones into the 3.5 mm combo (headset) jack produces a constant buzz/hum and no audio whatsoever. On the same bad boot the internal speakers are also degraded (faint, noisy output). HDMI/DisplayPort audio (via the discrete NVIDIA codec) is unaffected.
The striking part: once the machine is in this state, it persists across a warm reboot (reboot) and across alsa force-reload. It is cleared only by a full power-off (shut down completely, unplug charger, hold the power button ~15–30 s to drain the rails, then power on). After such a cold boot, headphone and speaker output are perfectly clean and correct.
This matches a long-standing user observation that the problem "fixes itself the next day" — i.e. after the laptop has been fully powered off overnight.
To reproduce
- Boot the machine (normally). On an affected boot, the analog output comes up in the bad state.
- Plug headphones into the 3.5 mm combo jack and play audio → only noise, no signal.
reboot (warm) → still broken.
sudo alsa force-reload → still broken (and notably leaves no SOF module-reload entries in dmesg — the SOF/DSP stack does not appear to actually reinitialize).
- Full shutdown + unplug + hold power button 15–30 s + power on → fixed (clean audio).
Reproduction rate
Intermittent — occurs on a subset of cold boots. Once in the bad state it is 100% persistent across warm reboots until a full power-off.
Expected behavior
Headphone (and speaker) analog output should work on every boot, as it does on Windows on the same hardware.
Key diagnostic observations
These are the most useful clues:
-
Kernel init logs are byte-for-byte identical between a failing boot and a working boot. Same firmware (2:2:0-57864, ABI 3:22:1), same topology (sof-hda-generic-2ch.tplg), same ALC274 autoconfig. No errors, warnings, IPC timeouts, or xruns on the failing boot anywhere in dmesg. (Full dmesg from both boots attached.)
-
Codec register state is identical between failing and working boots. On the failing boot the headphone pin is configured correctly:
- Node
0x21 (HP, combo jack): Amp-Out [0x00 0x00] (unmuted), Pin-ctls 0xc0 OUT HP, Connection: 0x02* 0x03 (source = DAC 0x02), Power D0.
- Node
0x17 (internal speaker): source = DAC 0x03.
So the codec is set up correctly; audio simply does not reach the analog DAC(s) on the headphone path.
-
Codec-level workarounds have no effect on a failing boot (tried via hda-verb on /dev/snd/hwC1D0):
- Disabling mic-bias VREF on the combo-jack mic pin:
0x19 SET_PIN_WIDGET_CONTROL 0x00 → no change.
- Re-pointing the HP pin to the speaker's DAC:
0x21 SET_CONNECT_SEL 0x01 (DAC 0x03 instead of 0x02) → no change.
This is consistent with the failure being upstream of the codec (host/DSP not delivering the stream on the HP path) and/or a hardware-state latch that survives a warm reset.
Taken together: identical software state on good vs. bad boots + cleared only by a physical power-rail drain ⇒ this looks like a DSP/codec hardware-state issue that is not reset by a warm reboot, with no kernel-visible error to flag it.
Environment
- Device: Razer Blade 15 (2022),
RZ09-0421, board CH580, BIOS 1.09 (2022-02-22)
- SoC / PCH: Intel Alder Lake-P i9 12900H; PCH-P HD Audio controller
8086:51c8 (subsystem 1a58:201b)
- Codec: Realtek ALC274 (
snd_hda_codec_alc269 / ehdaudio0D0); combo headset jack (HP 0x21, Mic 0x19, both Ext-Right), internal speaker 0x17
- Driver:
sof-audio-pci-intel-tgl; machine driver skl_hda_dsp_generic
- SOF firmware:
intel/sof/sof-adl.ri, version 2:2:0-57864, ABI 3:22:1 (kernel ABI 3:23:1)
- Topology:
intel/sof-tplg/sof-hda-generic-2ch.tplg
- Kernel:
6.17.0-35-generic
- Distro: Ubuntu 24.04.4 LTS
- firmware pkg:
linux-firmware 20240318.git3b128b60-0ubuntu2.27
- Userspace: PipeWire 1.0.5, WirePlumber 0.4.17
Attached
dmesg-FAILING-boot.txt — full kernel log from a boot where the headphone output was dead
dmesg-WORKING-boot.txt — full kernel log from the immediately following cold boot where it worked
codec-WORKING-boot.txt — /proc/asound/card1/codec#0 (working boot)
alsa-info.txt — full alsa-info.sh output (working boot)
- (TODO)
codec#0 dump from a failing boot — capture next time it wedges
alsa-info.txt
codec-WORKING-boot.txt
dmesg-WORKING-boot.txt
dmesg-FAILING-boot.txt
What I've ruled out
snd_hda_intel.power_save (irrelevant under SOF).
- ALSA mixer state / Auto-Mute Mode.
- Forcing the legacy HD-audio driver (
snd-intel-dspcfg.dsp_driver=1) — did not help and disabled the DMIC array.
- Mic-bias VREF and HP-pin DAC source (codec-level), as above.
alsa force-reload.
Questions for maintainers
- Is this a known ADL + ALC274 (or
sof-hda-generic) issue where the analog playback path can come up wedged and survive a warm reset?
- What firmware-level debug would help? I can reproduce and capture SOF debug traces / IPC logs on the next failing boot — please point me at the dynamic-debug flags /
/sys/kernel/debug/sof artifacts you want.
[ADL][ALC274] Intermittent: combo-jack headphone output silent + constant noise; cleared only by full power-off, not warm reboot — Razer Blade 15 (2022) RZ09-0421
I've been experiencing a weird issue, very rarely when I boot up my laptop I get some kind of interference noise when I plug my headset with a mic into the 3.5 mm jack. The following is a bug report created with Claude Code after I've used it to try to fix the issue:
Describe the bug
On a subset of boots, the analog headphone output is dead: plugging headphones into the 3.5 mm combo (headset) jack produces a constant buzz/hum and no audio whatsoever. On the same bad boot the internal speakers are also degraded (faint, noisy output). HDMI/DisplayPort audio (via the discrete NVIDIA codec) is unaffected.
The striking part: once the machine is in this state, it persists across a warm reboot (
reboot) and acrossalsa force-reload. It is cleared only by a full power-off (shut down completely, unplug charger, hold the power button ~15–30 s to drain the rails, then power on). After such a cold boot, headphone and speaker output are perfectly clean and correct.This matches a long-standing user observation that the problem "fixes itself the next day" — i.e. after the laptop has been fully powered off overnight.
To reproduce
reboot(warm) → still broken.sudo alsa force-reload→ still broken (and notably leaves no SOF module-reload entries in dmesg — the SOF/DSP stack does not appear to actually reinitialize).Reproduction rate
Intermittent — occurs on a subset of cold boots. Once in the bad state it is 100% persistent across warm reboots until a full power-off.
Expected behavior
Headphone (and speaker) analog output should work on every boot, as it does on Windows on the same hardware.
Key diagnostic observations
These are the most useful clues:
Kernel init logs are byte-for-byte identical between a failing boot and a working boot. Same firmware (
2:2:0-57864, ABI3:22:1), same topology (sof-hda-generic-2ch.tplg), same ALC274 autoconfig. No errors, warnings, IPC timeouts, or xruns on the failing boot anywhere in dmesg. (Full dmesg from both boots attached.)Codec register state is identical between failing and working boots. On the failing boot the headphone pin is configured correctly:
0x21(HP, combo jack):Amp-Out [0x00 0x00](unmuted),Pin-ctls 0xc0 OUT HP,Connection: 0x02* 0x03(source = DAC 0x02), PowerD0.0x17(internal speaker): source = DAC0x03.So the codec is set up correctly; audio simply does not reach the analog DAC(s) on the headphone path.
Codec-level workarounds have no effect on a failing boot (tried via
hda-verbon/dev/snd/hwC1D0):0x19 SET_PIN_WIDGET_CONTROL 0x00→ no change.0x21 SET_CONNECT_SEL 0x01(DAC 0x03 instead of 0x02) → no change.This is consistent with the failure being upstream of the codec (host/DSP not delivering the stream on the HP path) and/or a hardware-state latch that survives a warm reset.
Taken together: identical software state on good vs. bad boots + cleared only by a physical power-rail drain ⇒ this looks like a DSP/codec hardware-state issue that is not reset by a warm reboot, with no kernel-visible error to flag it.
Environment
RZ09-0421, boardCH580, BIOS1.09(2022-02-22)8086:51c8(subsystem1a58:201b)snd_hda_codec_alc269/ehdaudio0D0); combo headset jack (HP0x21, Mic0x19, both Ext-Right), internal speaker0x17sof-audio-pci-intel-tgl; machine driverskl_hda_dsp_genericintel/sof/sof-adl.ri, version 2:2:0-57864, ABI 3:22:1 (kernel ABI 3:23:1)intel/sof-tplg/sof-hda-generic-2ch.tplg6.17.0-35-genericlinux-firmware 20240318.git3b128b60-0ubuntu2.27Attached
dmesg-FAILING-boot.txt— full kernel log from a boot where the headphone output was deaddmesg-WORKING-boot.txt— full kernel log from the immediately following cold boot where it workedcodec-WORKING-boot.txt—/proc/asound/card1/codec#0(working boot)alsa-info.txt— fullalsa-info.shoutput (working boot)codec#0dump from a failing boot — capture next time it wedgesalsa-info.txt
codec-WORKING-boot.txt
dmesg-WORKING-boot.txt
dmesg-FAILING-boot.txt
What I've ruled out
snd_hda_intel.power_save(irrelevant under SOF).snd-intel-dspcfg.dsp_driver=1) — did not help and disabled the DMIC array.alsa force-reload.Questions for maintainers
sof-hda-generic) issue where the analog playback path can come up wedged and survive a warm reset?/sys/kernel/debug/sofartifacts you want.