Repository navigation
[ARL-H] Crackling/distorted speaker audio after s2idle resume — Dell Pro Max 14 Premium MA14250 (sof_sdw, cs42l43-l0 + cs35l56-l23), only full reboot recovers #5991
Description
Hardware
- Laptop: Dell Pro Max 14 Premium MA14250 (SKU 0D32), BIOS 1.13.1
- Platform: Intel Core Ultra 200H (Arrow Lake-H), audio controller
8086:7728, driversof-audio-pci-intel-mtl - SoundWire peripherals: cs42l43 headset codec (
sdw:0:0:01fa:4243:01) + 4× cs35l56 smart amps (sdw:0:2:01fa:3556:01:2/:3,sdw:0:3:01fa:3556:01:0/:1) - Machine driver:
sof_sdw
Software
- Fedora 44, kernel
7.2.11-200.fc44.x86_64 - SOF firmware:
intel/sof-ipc4/arl/sof-arl.ri, booted FW version 2.14.1.1 - Topology:
intel/sof-ipc4-tplg/sof-arl-cs42l43-l0-cs35l56-l23.tplg(correct platform-specific topology) - alsa-sof-firmware 2025.12.2, linux-firmware 20260916
- PipeWire 1.6.9, WirePlumber 0.5.18 (EasyEffects also running as a PipeWire client)
mem_sleep_default=s2idle
Problem
After every s2idle suspend/resume cycle, the internal speaker output crackles/pops (static-like distortion). Audio is clean after boot; the problem appears only after a suspend/resume cycle.
Restarting the userspace PipeWire stack (pipewire, pipewire-pulse, wireplumber) does NOT cure it — only a full reboot restores clean audio. So the corruption lives in persistent DSP firmware / SoundWire link / codec state that a warm driver resume path does not reset, while a boot does.
Kernel-side observations
Codec/system resume looks clean, which is part of the problem — the failure is invisible to the driver:
- All cs35l56/cs42l43 PM callbacks return 0 (
cs35l56_sdw_system_resume returned 0,platform_pm_restore returned 0) - Amps re-apply calibration/tuning after resume (
Calibration applied,Tuning PID: ...) - SoundWire links re-enumerate; no
UNATTACHEDperipherals, no EIO/-110, no xrun/underrun or sdw parity errors in dmesg
Possibly relevant detail
Kernel logs: Topology: ABI 3:29:1 Kernel ABI 3:23:1 — the topology in alsa-sof-firmware 2025.12.2 advertises a newer ABI than the kernel (7.2.11). It loads, but this skew might matter for IPC4 widget/stream state handling across D3→D0.
Related reports (not duplicates)
- [Bug]: Severe audio distortion on Lenovo w/ Arrow Lake, ALC287 & dual CSC3556 amps #5575 — cs35l56 distortion via generic-topology fallback (different root cause: here the correct
sof-arl-cs42l43-l0-cs35l56-l23.tplgis used) - [BUG] Lenovo Yoga Slim 7 15ILL9 (LNL, 17aa:380e): CS42L43 stops responding after one s2idle resume, then blocks every system suspend; state survives S5, no re-probe when codec re-attaches #5959 — LNL cs42l43 unresponsive after s2idle (similar area, Lunar Lake)
- Bug Report: No SoundWire machine driver match for Dell XPS 13 DX13260 (Wildcat Lake) — CS35L56 speaker amps run unpatched/uncalibrated #5918 / #11320 — Dell + cs35l56 firmware issues on 7.2.x
- PR [upstream test] ASoC: SOF: Fix IPC reliability and post-resume SoundWire init #5671 — IPC4 reliability / SoundWire re-enumeration race on Arrow Lake-S
Next diagnostic step (planned)
Test whether a full PCI unbind/rebind of 0000:00:1f.3 (sof-audio-pci-intel-mtl) — i.e. DSP reset + firmware reload + SoundWire re-enumeration without reboot — cures the distortion. Result will be posted here; it distinguishes "driver-level state" from "codec-latched state".
Happy to provide alsa-info, SOF trace/firmware logs, pm_debug_messages+pm_print_times suspend logs (currently enabled), or test patches.
Activity
[-][ARL-H] Crackling/distorted speaker audio after s2idle resume — Dell Pro Max 14 Premium MA14250 (sof_sdw, cs42l43-l0 + cs35l56-l23), recovered by PipeWire restart[/-][+][ARL-H] Crackling/distorted speaker audio after s2idle resume — Dell Pro Max 14 Premium MA14250 (sof_sdw, cs42l43-l0 + cs35l56-l23), only full reboot recovers[/+]akhkifc-cyber commentedon Oct 20, 2026
Additional data point: hibernate (S4) resume does NOT trigger the distortion — audio is clean after an S4 cycle on this machine. The crackling appears specifically after s2idle. Expected, but it cleanly confirms the pattern: the corrupted state forms in the s2idle resume path and is only cleared by a full hardware re-init (boot or S4), never by userspace restarts.
Planned next step: after the next s2idle resume (while it crackles), run a PCI unbind/rebind of
0000:00:1f.3(sof-audio-pci-intel-mtl) with PipeWire stopped — i.e. DSP reset + FW reload + SoundWire re-enumeration without reboot. Will report here whether that clears it:akhkifc-cyber commentedon Oct 20, 2026
Update: the distortion did NOT reproduce across 6 consecutive s2idle suspend/resume cycles on kernel
7.2.11-200.fc44.x86_64+ SOF FW 2.14.1.1 — audio clean after each resume.Context: kernel 7.2.11 was installed on this machine on Oct 17 (previously 7.2.10), and the user had been avoiding suspend, so the crackling was last observed on an older kernel. This suggests the issue may have been fixed upstream between 7.2.10 and 7.2.11 (possibly by the IPC4 reliability / SoundWire resume-path work).
Caveats: the 6 test cycles were short (10–55 s each); a longer suspend or specific stream/D0i3 conditions may still trigger it. Plan: use s2idle normally for several days (including long sleeps). If it stays clean, I'll close this issue as fixed-in-7.2.11; if it reproduces, I'll run the PCI unbind/rebind cure-test and post full logs.
charleskeepax commentedon Oct 21, 2026
Hm... I don't see anything between 7.2.10 and 7.2.11 that looks like it should affect this, but keep an eye on the situation and report back if you see the issue return. A full dmesg whilst the crackling is happening would be a good place to start for debugging.