Dell Pro 14 Plus PB14250 (Core Ultra 7 255U, CS42L43): microphone hw:0,4 capture fails with pcm_read EIO

[altger]

System

• Laptop: Dell Pro 14 Plus PB14250
• CPU: Intel Core Ultra 7 255U (Arrow Lake-U)
• BIOS: 2.16.0; DMI BIOS date 08/03/2026
• Distribution: Arch Linux
• Running kernel: 7.2.7-arch1-1
• Installed packages: linux 7.2.7.arch1-1 sof-firmware 2026.09.1-1 alsa-ucm-conf 1.2.16.1-1 pipewire 1:1.6.9-1 wireplumber 0.5.17-2
• Audio card: sof-soundwire, ALSA card 0
• Internal microphone: ALSA device 4 (hw:0,4), CS42L43 over SoundWire
• Selected topology in boot log: intel/sof-ipc4-tplg/sof-arl-cs42l43-l0.tplg
• SOF firmware version reported at boot: 2.15.0.1

Expected behavior

Recording from the internal microphone for three seconds should deliver approximately
three seconds of PCM audio without an ALSA read error.

Actual behavior

Hardware parameters are accepted at S16_LE, 48 kHz, stereo, but arecord fails
during capture:

arecord: pcm_read:2285: read error: Input/output error

Both hw:0,4 and plughw:0,4 produce the same read-time error.
PipeWire recording is also affected: an approximately eight-second pw-record
session produced a 48 kHz stereo WAV reporting only 0.512 seconds of audio.
A separate approximately one-second test reported 0.192 seconds.

The recorded audio file playback sounds like it's on a fast-forward rewind.

The issue persists after a complete Arch upgrade, reboot, and full shutdown/power-on.
The hardware microphone-mute/privacy control was checked and is off.

Reproduction

arecord -D hw:0,4 -v -f S16_LE -r 48000 -c 2 -d 3 /dev/null

For comparison:

arecord -D plughw:0,4 -v -f S16_LE -r 48000 -c 2 -d 3 /dev/null

Both reach recording and then fail at pcm_read. The verbose hw: output reports
exact rate 48000 and accepted S16_LE stereo parameters.

Other observations

• PipeWire's default audio source maps to the same sof-soundwire card 0,
  device 4 microphone.
• Mixer controls show cs42l43 Microphone Capture Switch as on,on.
  Decimators 3/4 are on and feed DP1TX1/2.
• The checked two-minute kernel-journal window around a failed capture had
  no entries. Boot logs show the SOF firmware and topology loading.
• Boot log reports topology ABI 3:29:1 and kernel ABI 3:23:1. I am including
  this as context, not claiming it causes the failure.

Please advise which additional ALSA/SOF or SoundWire diagnostics would help
identify the read-time failure.

[altger]

This is a follow up post after deep dive led by GPT-6.1 Sol (High). Sorry for that approach but I am total noob when it comes to sound hardware and firmware. Here's the summary of tested fix and possible root cause.

I've attached the working tplg as txt - remove the txt suffix, github rejected attaching the .tplg file.

Update: the microphone now works with the current kernel and SOF firmware after correcting one input channel-map value in the topology.

The working configuration remains:

• Dell Pro 14 Plus PB14250, Intel Core Ultra 7 255U

• Kernel 7.2.7-arch1-1

• sof-firmware 2026.09.1-1, running firmware 2.15.0.1

• CS42L43 microphone on sof-soundwire, PCM hw:0,4

Isolated topology change

Comparing the decoded cached topologies showed that the microphone ALH copier’s input channel map changed between the previously working 2025.12.2-1 package and 2026.09-1:

Widget: alh-copier.Capture-SmartMic.0
Pipeline: 41
Token: SOF_TKN_CAVS_AUDIO_FORMAT_IN_CH_MAP (1904)
Previously working topology: 0xffffff10

New topology:                0x00000000

The topology binaries in 2026.09-1 and 2026.09.1-1 are identical, so the September 30 maintenance upgrade did not change this topology.

I patched the original new binary directly, restoring only this input channel-map value to 0xffffff10. Byte comparison confirmed that exactly four bytes changed, with every other byte—including block headers and pipeline indices—preserved.

File size: 71230 bytes

Value offset: 0x96f2

Bytes: 00 00 00 00 → 10 ff ff ff

Original SHA256:

8693a7d7a8d9e9e1e1c69a46fad90bac78ca919f6ce82e9a217842e830d68372
Patched SHA256:

51552670b4ffcf6ae17ecc2a69d7eaaa693b70bf4640b33ce14097fb665982a3

Before-and-after results

All tests used direct ALSA capture at S16_LE, 48 kHz, stereo, with PipeWire/WirePlumber stopped during testing.

Test	Original topology	Patched topology
One-second capture, period 240 frames, buffer 960 frames	16.141 seconds; exit 0	1.159 seconds; exit 0
Three-second capture, default period 6000 frames and buffer 24000 frames	EIO after approximately 0.64 seconds	3.140 seconds; exit 0

The original failing configuration now succeeds:

arecord -D hw:0,4 -v -f S16_LE -r 48000 -c 2 \
    -d 3 /tmp/mic-check.wav

PipeWire capture, application microphone indicators, and voice transcription also work with the patched topology.

Additional evidence from the broken configuration

With 240-frame periods, kernel tracing showed host DMA period interrupts approximately every 80 ms, rather than the expected 5 ms. PCM position advanced by 240 frames per interrupt, corresponding to approximately 3000 frames/second instead of 48000. /proc/asound pointer observations agreed with this approximately 16× slowdown.

S32_LE also exhibited the original failure/slowdown, so it was not specific to S16_LE.

The suspected mechanism is the IPC4 ALH channel-mask calculation deriving its channel count from ch_map. A zero map can produce a zero count and an invalid GENMASK(step - 1, 0) calculation. I have not captured the resulting runtime channel mask, so that precise mechanism still needs confirmation; the successful four-byte topology correction is experimentally verified.

The temporary workaround selects the patched file through:

options snd_sof tplg_filename=mic-chmap-test.tplg

Could maintainers check why this topology now emits a zero microphone ALH input channel map, and whether the driver should reject or handle that value? I can provide the original and patched binaries, decoded configurations, and kernel trace.

mic-chmap-test.tplg.txt

[charleskeepax]

Hmm... yeah looks like something has changed on the topology side.

@bardliao I am not really familiar enough with the topology stuff, do you think it could relate to this patch from Richard: thesofproject/sof#11036

[bardliao]

Hmm... yeah looks like something has changed on the topology side.

@bardliao I am not really familiar enough with the topology stuff, do you think it could relate to this patch from Richard: thesofproject/sof#11036

Not likely. hw:0,4 is SDW DMIC. So the impacted conf file should be sdw-dmic-generic.conf

[kv2019i]

The changed definitions are for the chmap. The working value is for stereo CHMAP:

common_definitions.conf
» CHANNEL_MAP_MONO» » » 0xFFFFFFF0
» CHANNEL_MAP_STEREO» » » 0xFFFFFF10

@bardliao I can reproduce the build and will continue with a bisect to see where the wrong value is added. This looks odd as there we don't set a zero chmap anywhere, but yet such values gets into the final tplg (but not across the board, most chmap definitions are expected).

[kv2019i]

It's not a toolchain error at least, generating v2.14 topologies with the alsa-lib/utils we used for v2.15 release is ok. So this must be a regression in recent topology commits. Bisect in progress....