ALC298 (Samsung Galaxy Book3 Ultra NP960XFH): speakers silent after s2idle resume — SOF DSP audio path broken

[KiloHertzian]

Summary

Internal speakers work after cold boot but go completely silent after s2idle suspend/resume. Only a full reboot restores audio. The problem has two layers: (1) the kernel's ALC298 V2 4-amp fixup only runs at probe time, not on resume, and (2) the SOF DSP itself fails to re-establish the audio path after resume — even manually replaying the amp init does not restore sound.

Hardware

Component	Detail
Laptop	Samsung Galaxy Book 960XFH (NP960XFH_XA1US)
CPU	13th Gen Intel i7-13700H (Raptor Lake)
Codec	Realtek ALC298, Vendor 0x10ec0298, Subsystem 0x144dc1cc
Driver	SOF (sof-audio-pci-intel-tgl) via snd_soc_skl_hda_dsp
SOF FW	intel/sof/sof-rpl.ri version 2:2:0-57864
Topology	intel/sof-tplg/sof-hda-generic-2ch.tplg
Kernel	6.19.11-1-cachyos (also observed on 6.19.10)
Suspend mode	s2idle ([s2idle] deep)
Distro	CachyOS (Arch-based), PipeWire 1.6.3

Steps to Reproduce

1. Cold boot — internal speakers work, speaker-test -c 2 -t sine -l 1 produces audio
2. Suspend (s2idle): close lid or systemctl suspend
3. Resume: open lid
4. Attempt playback — completely silent

Observed Behavior After Resume

HDA codec state

Pin 0x14 (internal speaker, Fixed) shows hardware mute after resume:

Node 0x14 [Pin Complex] wcaps 0x40050d: Stereo Amp-Out
  Amp-Out vals:  [0x80 0x80]   ← hardware-muted

Pin 0x17 (kernel's active speaker line_out) is unmuted but no audio reaches speakers:

Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out vals:  [0x00 0x00]

SOF DSP state

• PCM open returns -112 (EHOSTDOWN) immediately after resume
• After PipeWire restart, PCM opens successfully but no audio reaches speakers
• PCI runtime_status may show suspended even during active playback attempt
• aplay -D hw:0,0 /usr/share/sounds/... also produces no audio (rules out PipeWire)

What was tried (none restore audio)

#	Action	Result
1	Unmute + enable pin 0x14 via hda-verb	No effect
2	Full V2 4-amp init via hda-verb (coefficients on Node 0x20 for NIDs 0x38, 0x39, 0x3C, 0x3D)	Coefficients written OK, still no sound
3	Restart PipeWire + WirePlumber	PCM opens, still silent
4	Amp init while audio streaming	No sound
5	Kill PipeWire + modprobe -r + modprobe SOF modules	Module remove fails (device in use) or reload doesn't restore
6	Direct ALSA playback (aplay -D hw:0,0)	Silent — hardware-level issue
7	PCI remove + rescan (echo 1 > .../remove; echo 1 > .../rescan)	Restores codec detection but not audio; reboot still needed

Root Cause Analysis

Layer 1: Kernel V2 fixup only runs at probe

The Samsung 4-amp quirk (ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS, SSID 144d:c1cc) initializes amp coefficients via Node 0x20 only at HDA_FIXUP_ACT_PROBE:

// sound/pci/hda/patch_realtek.c
static void alc298_fixup_samsung_amp_v2_4_amps(struct hda_codec *codec,
            const struct hda_fixup *fix, int action)
{
    if (action == HDA_FIXUP_ACT_PROBE)   // NOT on resume (HDA_FIXUP_ACT_INIT)
        alc298_samsung_v2_init_amps(codec, 4);
}

After s2idle, the amp coefficient state is lost and never re-initialized.

Layer 2: SOF DSP audio path is broken

Even after manually replaying the exact amp init sequence via hda-verb, audio does not work. The SOF DSP-to-codec link appears broken:

• The initial PCM open failure (EHOSTDOWN) suggests the SOF DSP did not resume correctly
• Even after recovery (PipeWire restart, module reload), audio frames do not reach the codec
• This is not just a missing amp init — the entire DSP pipeline is non-functional after resume

Boot Log (relevant lines)

snd_soc_avs 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 5
sof-audio-pci-intel-tgl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware file: intel/sof/sof-rpl.ri
sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:1
snd_hda_codec_alc269 ehdaudio0D0: ALC298: picked fixup for PCI SSID 144d:c1cc
snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC298: line_outs=1 (0x17) type:speaker

Additional Notes

• On one occasion after a forced reboot (caused by PipeWire D-state hang during shutdown on dead SOF device), the ALC298 codec disappeared entirely — codec mask became 4 (HDMI only) instead of 5. PCI remove+rescan recovered codec detection, but a full reboot was needed to restore audio.
• No custom modprobe.d configs (only nvidia.conf), no custom audio systemd services — stock SOF configuration.
• Regression window appears to be kernel 6.19.7–6.19.10 (audio previously survived suspend on earlier kernels, exact version not recorded).

Expected Behavior

Speakers should produce audio after s2idle resume without requiring a reboot. The SOF DSP should properly resume its audio pipeline, and the ALC298 V2 amp fixup should re-run on resume.

Related

• Joshua Grisham's V2 Samsung amp patch: https://lore.kernel.org/linux-sound/20240909193000.838815-1-josh@joshuagrisham.com/
• Samsung Galaxy Book extras: https://github.com/joshuagrisham/samsung-galaxybook-extras

[ujfalusi]

@KiloHertzian, can you elaborate on issue 2? We need more information of the errors the kernel report when audio is not available after suspend.
Can you attach the output of alsa-info.sh and verify few things when audio is not working after resume:
check if audio works in low-level with aplay (aplay -Dhw:0,0 <wav file> or speaker-test -Dhw:0,0 -c2 -t wav) and while running this check if the audio is actually played back: cat /proc/asound/card0/pcm0p/sub0/status if the hw_ptr is moving then audio is working from SOF point of view.

[KiloHertzian]

Closing — further investigation with dynamic debug and automated pre/post suspend captures revealed the original diagnosis was incorrect.

The SOF DSP resumes correctly (firmware loads, PCM opens, pipeline sets up). The amp fixup also re-runs properly on every D3→D0 transition. The actual issue is that the HDA codec pin default configuration registers (e.g., pin 0x17 flipping from 0x90170110 to 0x411111f0) are being corrupted during repeated HDA codec power save cycling — not during system suspend/resume specifically. This appears to be an HDA core / Realtek codec issue rather than a SOF issue.

Apologies for the noise.

[KiloHertzian]

@ujfalusi Thanks for looking at this. Here's what we found with further investigation that led to the closure:

SOF DSP is working correctly

Dynamic debug on snd_sof* and snd_hda_codec* modules confirmed the DSP resumes properly every time. Firmware loads, pipelines set up, PCM opens:

sof-audio-pci-intel-tgl 0000:00:1f.3: fw_state change: 0 -> 2
sof-audio-pci-intel-tgl 0000:00:1f.3: loading firmware
sof-audio-pci-intel-tgl 0000:00:1f.3: IMR restore supported, booting from IMR directly
sof-audio-pci-intel-tgl 0000:00:1f.3: firmware boot complete
sof-audio-pci-intel-tgl 0000:00:1f.3: fw_state change: 6 -> 7
sof-audio-pci-intel-tgl 0000:00:1f.3: pcm0 (HDA Analog), dir 0: Entry: open
sof-audio-pci-intel-tgl 0000:00:1f.3: widget PIPELINE.30.HDA0.OUT setup complete
sof-audio-pci-intel-tgl 0000:00:1f.3: widget PCM0P setup complete

The amp fixup also fires correctly on every D3→D0 transition (22 times in a 33-minute window):

snd_hda_codec_alc269 ehdaudio0D0: ALC298: Apply fix-func for (null)
snd_hda_codec_alc269 ehdaudio0D0: alc298_samsung_v2: Enabled speaker amp 0x38
snd_hda_codec_alc269 ehdaudio0D0: alc298_samsung_v2: Enabled speaker amp 0x39
snd_hda_codec_alc269 ehdaudio0D0: alc298_samsung_v2: Enabled speaker amp 0x3c
snd_hda_codec_alc269 ehdaudio0D0: alc298_samsung_v2: Enabled speaker amp 0x3d

Actual root cause: pin default config register corruption

Automated pre/post suspend codec dumps (/proc/asound/card0/codec#0) revealed that the pin default configuration registers are being silently corrupted during HDA codec power save cycling (D3↔D0), not during system suspend:

Pin	Working (after boot)	Broken (after repeated D3↔D0 cycles)
0x17 (speaker)	0x90170110 [Fixed Speaker]	0x411111f0 [disabled]
0x21 (headphone)	0x04211050 [Jack HP Out]	0x411111f0 [disabled]
0x19 (mic)	0x04a11020 [Jack Mic]	0x01a19050 [different config]

The corruption occurred between two captures taken 35 minutes apart while the laptop was awake (no system suspend between them). Journal shows 22 D3↔D0 power save cycles in that window.

This appears to be an HDA core / Realtek codec issue — pin overrides set at HDA_FIXUP_ACT_PRE_PROBE are not surviving repeated codec power save cycles. We haven't yet tested disabling power_save to confirm.

Sorry for initially filing this against SOF — the original diagnosis was based on incomplete data.

[ujfalusi]

@KiloHertzian , no problem and thank you for the update, we really appreciate the feedback!