pipeline: RPL DMIC capture stalls after startup on Xiaomi REDMI Book 14 2025 with IPC3; IPC4 works

Summary

The internal digital microphone array on a Xiaomi REDMI Book 14 2025 stops producing audio shortly after capture starts when the default SOF IPC3 firmware is used.

Capture begins with a loud transient. After approximately 300 ms, both channels become a constant sample value and remain unchanged for the rest of the stream. This reproduces through PipeWire and through direct raw ALSA capture from both exposed DMIC PCMs.

Forcing SOF IPC4 with snd_sof.ipc_type=1 fixes continuous microphone capture on the same hardware. IPC4 uses the packaged Intel-signed firmware and does not require replacing any firmware files.

Environment

The firmware reports two DMICs in NHLT. ALSA exposes:

card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*)
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*)

NHLT microphone metadata contains two front-panel subcardioid microphones at horizontal offsets -45 and +45 degrees.

Broken configuration: default IPC3

No IPC override is used.

Firmware paths/files for ipc type 0:
 Firmware file: intel/sof/sof-rpl.ri
 Topology file: intel/sof-tplg/sof-hda-generic-2ch.tplg
Firmware info: version 2:2:0-57864
Firmware: ABI 3:22:1 Kernel ABI 3:23:1
DMICs detected in NHLT tables: 2

The sound card, speaker and both microphone sources register normally. There are no mute, permission or PipeWire service errors.

Steps to reproduce

1. Boot with the default IPC3 selection.

2. Confirm that ALSA exposes DMIC devices 6 and 7:

   arecord -l

3. Suspend or stop any process holding the capture device, then record directly from the 48 kHz DMIC PCM:

   arecord -D hw:0,6 -f S32_LE -r 48000 -c 2 -d 5 dmic-ipc3-48k.wav

4. The same failure can be reproduced on the 16 kHz endpoint:

   arecord -D hw:0,7 -f S16_LE -r 16000 -c 2 -d 5 dmic-ipc3-16k.wav

5. Recording through PipeWire also reproduces the problem:

   arecord -D pipewire -f S16_LE -r 48000 -c 2 -d 5 dmic-ipc3-pipewire.wav

The problem reproduced on every tested IPC3 capture path: PipeWire, raw ALSA device 6 and raw ALSA device 7.

Expected result

The internal microphone array should continuously capture acoustic input for the duration of the stream.

Actual result

On raw ALSA device 6:

• During the 100-200 ms and 200-300 ms windows, the capture reaches 0 dBFS and produces the audible harsh transient.

• From 300 ms onward, each 100 ms analysis window has identical statistics:

  Peak level: -58.940595 dBFS
  RMS level:  -58.940595 dBFS
  Entropy:     0.000000
  

• The equal peak and RMS levels with zero entropy are caused by every sample having the same fixed value, not by environmental silence.

• Speaking, tapping near the microphone and changing input gain have no effect after the stream stalls.

The 16 kHz PCM similarly becomes a constant value after startup. Direct ALSA capture proves that the failure occurs below PipeWire and application permission/routing layers.

Working configuration: IPC4

Add this kernel command-line parameter:

snd_sof.ipc_type=1

The driver then loads:

Module parameter used, overriding default IPC 0 to 1
Firmware paths/files for ipc type 1:
 Firmware file: intel/sof-ipc4/rpl/sof-rpl.ri
 Firmware lib path: intel/sof-ipc4-lib/rpl
 Topology file: intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
Loaded firmware library: ADSPFW, version: 2.12.0.1
Booted firmware version: 2.12.0.1

With IPC4, the internal microphone continuously records speech and ambient sound. The kernel log contains no SOF timeout, xrun, overrun or underrun errors. A brief startup transient may still occur occasionally, but capture no longer stalls.

Additional diagnostic result

The community-signed IPC3 image is not a usable workaround on this machine. When explicitly selected, the platform firmware rejects it:

Firmware file: intel/sof/community/sof-rpl.ri
error code: 0x2c (error: signature verification failed)
error: failed to boot DSP firmware -110

The normal Intel-signed IPC3 and IPC4 images both boot successfully; only the default IPC3 path exhibits the capture stall.

Impact

Without the IPC4 override, the built-in microphone is unusable in recording applications, browsers and calls. Users may incorrectly diagnose this as failed microphone hardware because the device is visible but stops responding immediately after capture starts.

Diagnostic logs

Sanitized full logs are available in this GitHub Gist:

https://gist.github.com/Jerriel0915/c715ab1e265618a3471a593330e27d90

The Gist contains:

• ipc3-kernel.log: full kernel log from a boot using the default IPC3 firmware.
• ipc4-kernel.log: full kernel log from a boot using snd_sof.ipc_type=1.
• alsa-info-ipc4.txt: alsa-info.sh output from the working IPC4 configuration.

Filesystem UUIDs, local paths and network MAC addresses were redacted before upload.

Questions for maintainers

1. Is forcing IPC4 the recommended long-term workaround for this Raptor Lake platform?
2. Would a DMI quirk selecting IPC4 for XIAOMI / REDMI Book 14 2025 / TM2417 be appropriate?
3. Which additional SOF trace or NHLT data would help identify why the IPC3 DMIC pipeline stops delivering samples?