You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary
On a Dell Precision 5690 (Meteor Lake), internal DMIC capture intermittently produces a full-scale impulse train instead of audio. The failed state is sticky at the hardware level: it survives stream reopen, suspend/resume, warm reboot, and a full unload/reload of the entire SOF + SoundWire + codec module chain. It is cleared only by a cold power-off. A working mic can flip into the failed state at runtime on an audio topology reconfiguration (e.g. USB audio device hotplug).
This is on the same machine model as #9852 (closed as OEM-related), but the evidence here is materially different from that report: the mic-mute hotkey has no effect on this failure mode (tested), no BIOS settings were changed, and the failure is quantified data-stream corruption rather than "no capture". Filing separately because the warm-vs-cold-boot asymmetry points at something actionable in the driver stack: codec/bus state that is not fully reset at initialization. Windows on the same machine always captures correctly, so the hardware is healthy and correct handling of this board is achievable in software.
Reproduced on SOF firmware 2.13.0.1 and 2.14.1.1 (sof-bin 2025.05.1) — both affected
Symptom (quantified)
Captured audio is a full-scale impulse train: peaks pinned at ±32768, 300–3000 large discontinuities/sec (counting |sample-to-sample delta| > 8000 at 48 kHz S16). Affects PipeWire and direct arecord from the DMIC PCM equally, in both S16_LE and S32_LE (hw params are fixed 48 kHz/2ch). In one capture taken right after suspend/resume while in the failed state, the corruption was exactly periodic: ~22 glitches/sec = one per ~2180-sample period — i.e. one glitch per DMA period, suggesting a clock/sample-slip.
Failed-state persistence (the key observation)
Once entered, the failed state survives, in increasing order of teardown depth:
Stream close/reopen (all clients)
suspend/resume (s2idle)
Warm reboot
Full module chain reload (modprobe -r of snd_sof_pci_intel_mtl, snd_soc_sof_sdw, snd_soc_rt712_sdca, snd_soc_rt712_sdca_dmic, snd_soc_rt1316_sdw, snd_soc_sdw_utils, soundwire_intel, soundwire_cadence, soundwire_generic_allocation, regmap_sdw, regmap_sdw_mbq, soundwire_bus, and all snd_sof_* — then modprobe back). The card re-appears, the DSP re-boots firmware, but capture is still corrupted.
A cold power-off (poweroff, ~10 s, power on) reliably restores clean capture. This likely explains the common "mic works or breaks depending on kernel version" reports for these machines: kernel updates always warm-reboot, carrying the bad state across — the kernel-version correlation is (at least partly) spurious.
Entering the failed state
Reproduced entering the failed state from a verified-working session by unplugging a USB audio device (Logitech C920), which caused PipeWire to re-open the DMIC stream. Clean capture immediately before; impulse-train corruption immediately after; state then stuck through everything except cold power-off.
Other observations
soundwire sdw:0:x:025d:xxxx: PARITY error detected before INT mask is enabled at boot appears on both good and bad boots — appears unrelated.
After a shallow modprobe -r snd_sof_pci_intel_mtl + reload (without removing soundwire/codec modules), the machine driver fails to re-probe: sof_sdw: probe with driver sof_sdw failed with error -12; a sysfs bind retry returns EIO. Only the full chain removal above re-creates the card.
Will capture alsa-info + dmesg in the failed state on next occurrence and attach here.
Happy to test patches or provide sof-logger traces — the failed state can be entered on demand often enough (audio hotplug) and cleared deterministically (cold boot) to make A/B testing practical.
Summary
On a Dell Precision 5690 (Meteor Lake), internal DMIC capture intermittently produces a full-scale impulse train instead of audio. The failed state is sticky at the hardware level: it survives stream reopen, suspend/resume, warm reboot, and a full unload/reload of the entire SOF + SoundWire + codec module chain. It is cleared only by a cold power-off. A working mic can flip into the failed state at runtime on an audio topology reconfiguration (e.g. USB audio device hotplug).
This is on the same machine model as #9852 (closed as OEM-related), but the evidence here is materially different from that report: the mic-mute hotkey has no effect on this failure mode (tested), no BIOS settings were changed, and the failure is quantified data-stream corruption rather than "no capture". Filing separately because the warm-vs-cold-boot asymmetry points at something actionable in the driver stack: codec/bus state that is not fully reset at initialization. Windows on the same machine always captures correctly, so the hardware is healthy and correct handling of this board is achievable in software.
System
sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplgSymptom (quantified)
Captured audio is a full-scale impulse train: peaks pinned at ±32768, 300–3000 large discontinuities/sec (counting |sample-to-sample delta| > 8000 at 48 kHz S16). Affects PipeWire and direct
arecordfrom the DMIC PCM equally, in both S16_LE and S32_LE (hw params are fixed 48 kHz/2ch). In one capture taken right after suspend/resume while in the failed state, the corruption was exactly periodic: ~22 glitches/sec = one per ~2180-sample period — i.e. one glitch per DMA period, suggesting a clock/sample-slip.Failed-state persistence (the key observation)
Once entered, the failed state survives, in increasing order of teardown depth:
modprobe -rof snd_sof_pci_intel_mtl, snd_soc_sof_sdw, snd_soc_rt712_sdca, snd_soc_rt712_sdca_dmic, snd_soc_rt1316_sdw, snd_soc_sdw_utils, soundwire_intel, soundwire_cadence, soundwire_generic_allocation, regmap_sdw, regmap_sdw_mbq, soundwire_bus, and all snd_sof_* — then modprobe back). The card re-appears, the DSP re-boots firmware, but capture is still corrupted.A cold power-off (poweroff, ~10 s, power on) reliably restores clean capture. This likely explains the common "mic works or breaks depending on kernel version" reports for these machines: kernel updates always warm-reboot, carrying the bad state across — the kernel-version correlation is (at least partly) spurious.
Entering the failed state
Reproduced entering the failed state from a verified-working session by unplugging a USB audio device (Logitech C920), which caused PipeWire to re-open the DMIC stream. Clean capture immediately before; impulse-train corruption immediately after; state then stuck through everything except cold power-off.
Other observations
soundwire sdw:0:x:025d:xxxx: PARITY error detected before INT mask is enabledat boot appears on both good and bad boots — appears unrelated.modprobe -r snd_sof_pci_intel_mtl+ reload (without removing soundwire/codec modules), the machine driver fails to re-probe:sof_sdw: probe with driver sof_sdw failed with error -12; a sysfs bind retry returns EIO. Only the full chain removal above re-creates the card.Logs
Happy to test patches or provide sof-logger traces — the failed state can be entered on demand often enough (audio hotplug) and cleared deterministically (cold boot) to make A/B testing practical.