[BUG, ADL, DMIC] Alder Lake SoF DMIC (pci-0000_00_1f.3 / sof-adl-max98357a-rt5682) intermittently fails

[davislcruz]

---

Describe the bug

On Alder Lake, the SoF digital microphone input (DMIC) sometimes fails when an app tries to start microphone capture.

The failing device is:

• hw:0,100
• pro-input-100

The failure happens during ALSA set_hw_params and returns:

• Invalid argument

When this happens, PipeWire capture clients can fail immediately on startup. One example is wiremix, but the problem also affects other apps that try to open the DMIC.

This issue is intermittent. The same settings may work on one launch and fail on another.

I tested multiple buffer sizes, period settings, and sample formats:

• S16LE fails randomly
• S32LE also fails randomly
• S24LE with smaller buffers is fully stable

The only configuration that consistently fixes the issue for me is:

• S24LE
• small buffers
• period-size=256
• periods=4
• buffer-bytes=6144
• disable-mmap=true

So the problem appears to be related to certain hardware parameter combinations being accepted only inconsistently by the driver or firmware.

---

Workarounds tried

I tested these workarounds:

• changing PipeWire and WirePlumber buffer and period settings

• switching format from S16LE to S32LE

• forcing a stable config:

  • S24LE
  • period-size=256
  • periods=4
  • buffer-bytes=6144
  • disable-mmap=true

Results:

• S16LE still fails randomly
• S32LE still fails randomly
• S24LE with the settings above gives 0 failures

---

To reproduce

1. Start PipeWire and WirePlumber

2. Launch any app that opens the DMIC capture device

3. The easiest test case is wiremix

4. About 1 out of 4 launches fails with:

   • Start error: Invalid argument

Reproduction command

Run this from foot under swayfx:

DWELL=3 /tmp/wiremix-investigate/wiremix-crash-test-long.sh 40

---

Test script used

#!/usr/bin/env bash
set -euo pipefail

OUTDIR=/tmp/wiremix-investigate/crash
mkdir -p "$OUTDIR"

APP_ID=wiremixterm
iters=${1:-120}

dwell=${DWELL:-3.0}

check_proc() {
  pgrep -u "$(id -u)" -x wiremix >/dev/null 2>&1
}

fails=0
invalid=0

for i in $(seq 1 "$iters"); do
  tag="crashlong_$(printf '%03d' $i)_$(date +%H%M%S)"
  log="$OUTDIR/${tag}.log"

  swaymsg "[app_id=\"$APP_ID\"] kill" >/dev/null 2>&1 || true
  pkill -x wiremix 2>/dev/null || true

  footclient -N -a "$APP_ID" -T "$APP_ID" --hold \
    sh -lc "script -q -c 'wiremix' '$log'" &

  sleep "$dwell"
  p=0
  if check_proc; then p=1; fi

  if [ $p -eq 0 ]; then
    fails=$((fails+1))
    if rg -q 'Start error: Invalid argument' "$log"; then
      invalid=$((invalid+1))
    fi
  fi

  swaymsg "[app_id=\"$APP_ID\"] kill" >/dev/null 2>&1 || true
  pkill -x wiremix 2>/dev/null || true
  sleep 0.4
done

echo "fails=$fails/$iters invalid=$invalid/$iters"

---

Reproduction rate

With the default parameters:

• format: S16LE
• rate: 16000
• period size: 512
• periods: 64

I see about:

• 10 to 12 failures out of 40 launches
• roughly 1 in 4 launches fail

With the workaround settings:

• format: S24LE
• small buffers

I get:

• 0 failures out of 40 launches

---

Expected behavior

The DMIC capture device should reliably accept valid hardware parameters every time and allow microphone capture clients to start without random failures.

---

Actual behavior

The DMIC intermittently rejects hardware parameters during set_hw_params, returning Invalid argument.

When that happens, apps that try to open the microphone can fail immediately on launch.

---

Impact

This is a showstopper for microphone capture on the internal DMIC.

Because the failure is random, any app that uses this microphone may fail unpredictably, including:

• wiremix
• audio recorders
• other PipeWire capture clients

---

Environment

Kernel / firmware

• Kernel: 6.12.76_1 on Void Linux
• SOF firmware: sof-firmware-2025.12.2_1

I do not have the upstream commit hashes because these came from distro packages.

Desktop environment

• Wayland compositor: swayfx
• Terminal: foot

Topology

• intel/sof-tplg/sof-adl-max98357a-rt5682.tplg

From dmesg:

sof-audio-pci-intel-tgl 0000:00:1f.3:  Topology file: intel/sof-tplg/sof-adl-max98357a-rt5682.tplg

Platform

• Alder Lake
• PCI device: 0000:00:1f.3
• driver: sof-audio-pci-intel-tgl

---

Console output

PipeWire SPA ALSA log

This is the intermittent failure:

hw:0,100c: format:S16_LE access:mmap-interleaved rate:16000 channels:2
period frames 512, periods 64, buffer frames 32768
set_hw_params: Invalid argument

Kernel log excerpt

sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx error for 0x60010000 (msg/reply size: 108/20): -5
sof-audio-pci-intel-tgl 0000:00:1f.3: HW params ipc failed for stream 1
sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_pcm_component_hw_params on 0000:00:1f.3: -5

---

Stable workaround

This configuration completely avoids the issue in my testing:

format: S24_LE
rate: 16000
channels: 2
period-size: 256
periods: 4
buffer-bytes: 6144
access: RW_INTERLEAVED
disable-mmap: true

---

Additional logs

I can provide full logs on request, including:

• PipeWire debug logs
• dmesg
• sof-logger

Commands used:

# enable PipeWire debug
export SPA_LOG_LEVEL=5
export SPA_DEBUG=alsa:5
export PIPEWIRE_DEBUG=4

# reproduce, then grab logs
DWELL=3 /tmp/wiremix-investigate/wiremix-crash-test-long.sh 40
cp ~/.local/state/user-runit/pipewire.log /tmp/pipewire-debug.log
sudo dmesg > /tmp/dmesg.log

---

[kv2019i]

@davislcruz Thank you for detailed report! The longer dmesg log (and if possible sof-logger log) would be helpful.

Can you reproduce this with arecord? Something like:
arecord -Dhw:0,100 -v -r16000 -c2 -fS16_LE -traw /dev/null

[davislcruz]

Thanks for the suggestion. I was able to reproduce it with arecord as well.

Command used:

arecord -Dhw:0,100 -v -r16000 -c2 -fS16_LE -traw /dev/null

Output:

arecord: set_params:1456: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 16000
PERIOD_TIME: 125000
PERIOD_SIZE: 2000
PERIOD_BYTES: 8000
PERIODS: 4
BUFFER_TIME: 500000
BUFFER_SIZE: 8000
BUFFER_BYTES: 32000
TICK_TIME: 0

I can provide a longer dmesg log next. I’ll also try to capture a sof-logger log if I can get it set up.

[kv2019i]

@davislcruz does this happen every time with arecord? And can you provide output of "alsa-info"?

The PCM100 device on these devices was primarily used on Chromebooks for wake-on-voice capability (and Chromebooks shipped with custom FW and topology file). The upstream topologies do enable the PCM, but it is not really intended as the main PCM to use the PCH dmic for generic apps. The topology source is at:
https://github.com/thesofproject/sof/blob/stable-v2.2/tools/topology/topology1/sof-tgl-max98357a-rt5682.m4

# PCM1 <---> volume <----> SSP0  (Headset - ALC5682)
# PCM99 <---- volume <----- DMIC01 (dmic0 capture)
# PCM2 ----> volume -----> iDisp1
# PCM3 ----> volume -----> iDisp2
# PCM4 ----> volume -----> iDisp3
# PCM5 ----> volume -----> iDisp4
# PCM99 <---- volume <---- DMIC01 (dmic 48k capture)
# PCM100 <---- kpb <---- DMIC16K (dmic 16k capture)

That said, it still should work. But looking at the topology source for these device, PCM100 is really designed to work with S24_LE/S32_LE. So actual I'd expect the arecord to fail every time, and if this is the case, not sure why wiremix behaves like you see. dmesg+alsa-info should give more hints at what is happening.

[davislcruz]

Thanks @kv2019i for the follow-up. I re-collected everything from a clean run and attached:

audio-debug-fresh-20260403_004928.tar.gz

This bundle includes:

• arecord-hw0100-20260403_004928.txt
• arecord-hw0100-dmesg-window-20260403_004928.txt
• dmesg-after-arecord-20260403_004928.txt
• sof-trace-20260403_004928.txt
• alsa-info-20260403_004928.txt
• wpctl-sources-fix-OFF-20260403_004928.txt
• wpctl-sources-fix-ON-20260403_004928.txt

Exact commands used to generate these logs:

# Stop PipeWire/WirePlumber for direct ALSA repro
sv stop ~/.local/service/pipewire ~/.local/service/wireplumber ~/.local/service/pipewire-pulse || true
pkill -u "$(id -u)" -x pipewire wireplumber pipewire-pulse 2>/dev/null || true
pkill -u "$(id -u)" -f "pipewire-pulse\\.conf" 2>/dev/null || true

# arecord repro
arecord -Dhw:0,100 -v -r16000 -c2 -fS16_LE -traw /dev/null > arecord-hw0100-20260403_004928.txt 2>&1 || true

# dmesg window around repro
sudo dmesg -c >/dev/null
arecord -Dhw:0,100 -v -r16000 -c2 -fS16_LE -traw /dev/null > arecord-hw0100-dmesg-window-20260403_004928.txt 2>&1 || true
sudo dmesg -T > dmesg-after-arecord-20260403_004928.txt

# SOF trace
sudo mount -t debugfs none /sys/kernel/debug 2>/dev/null || true
sudo timeout 30s ~/.local/bin/sof-logger -t -l /lib/firmware/intel/sof/sof-tgl.ldc > sof-trace-20260403_004928.txt 2>&1 || true

# alsa-info
sudo alsa-info.sh --no-upload --output alsa-info-20260403_004928.txt

# Compare PipeWire source exposure with workaround OFF/ON

# OFF
mv ~/.config/wireplumber/wireplumber.conf.d/51-dmic16k-fix.conf ~/.config/wireplumber/wireplumber.conf.d/51-dmic16k-fix.conf.DISABLED 2>/dev/null || true
sv restart ~/.local/service/pipewire ~/.local/service/wireplumber ~/.local/service/pipewire-pulse || true
sleep 1
wpctl status | sed -n "/Sources:/,/Filters:/p" > wpctl-sources-fix-OFF-20260403_004928.txt

# ON
mv ~/.config/wireplumber/wireplumber.conf.d/51-dmic16k-fix.conf.DISABLED ~/.config/wireplumber/wireplumber.conf.d/51-dmic16k-fix.conf 2>/dev/null || true
sv restart ~/.local/service/pipewire ~/.local/service/wireplumber ~/.local/service/pipewire-pulse || true
sleep 1
wpctl status | sed -n "/Sources:/,/Filters:/p" > wpctl-sources-fix-ON-20260403_004928.txt

Let me know if you want me to also re-run this against S24_LE or S32_LE on hw:0,100.

audio-debug-fresh-20260403_004928.tar.gz

[kv2019i]

Thank you @davislcruz for the logs. So right, I can see from alsa-info this is a Chromebook device, so this makes a bit more sense. The PCM100 is really designed for Chromebook special usage and the DSP path has a keyphrase-buffer on the pipeline (for wake-on-voice). The upstream binary doesn't have an actual wake-on-voice algorithm (as you'd fine on commercial Chromebook images), and the public image in sof-bin just has a placeholder (implementation is in SOF upstream). This does set limits on how this can be used, so you will have failures on most regular apps (designed to work with Chromebook wake-on-voice user-space stack). E.g. this in sof-logger reveals:

[  3005980511.750983] (          31.041666) c0 pipe         11.59 ....../pipeline-params.c:340  INFO pipe prepare
[  3005980548.886398] (          37.135414) c0 kpb          11.54          src/audio/kpb.c:490  INFO kpb_prepare()
[  3005980574.407230] (          25.520832) c0 kpb          11.54          src/audio/kpb.c:1586 ERROR kpb: host_buffer_size (32000) must be at least 384000
[  3005980597.844729] (          23.437500) c0 pipe         11.59 ....../pipeline-params.c:347  ERROR pipeline_prepare(): ret = -22, dev->comp.id = 52
[  3005980619.615562] (          21.770832) c0 ipc                  src/ipc/ipc3/handler.c:313  ERROR ipc: pipe 11 comp 52 prepare failed -22
[  3005980638.000978] (          18.385416) c0 pipe         11.59 ......./pipeline-graph.c:346  INFO pipe reset
[  3005980728.730141] (          90.729164) c0 kpb                         src/audio/kpb.c:617  INFO kpb_reset(): resetting from state 3, state log 43333333
[  3005980747.636390] (          18.906250) c0 kpb                         src/audio/kpb.c:1536 INFO kpb_reset_history_buffer()
[  3005980765.188473] (          17.552082) c0 kpb                         src/audio/kpb.c:1451 INFO kpb_clear_history_buffer()

I would recommend to use PCM99 for dmic capture as that is designed to work with regular applications.

It is possible to modify the DSP topology (to leave the keyphrase buffer out), but then you have to have matching changes to Linux kernel machine driver for this hardware (machine driver and DSP topology need to be a match always).

I would lean towards closing this as works as specified. Pipewire clients cannot work with this special Chromebook PCM device. Hopefully PCM99 fits your needs.