Repository navigation
Dell Pro 14 Plus PB14250 (Core Ultra 7 255U, CS42L43): microphone hw:0,4 capture fails with pcm_read EIO #11271
Description
Activity
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-1sof-firmware 2026.09.1-1, running firmware2.15.0.1CS42L43 microphone on
sof-soundwire, PCMhw: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-1package and2026.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: 0x00000000The topology binaries in
2026.09-1and2026.09.1-1are 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 ffOriginal SHA256:
8693a7d7a8d9e9e1e1c69a46fad90bac78ca919f6ce82e9a217842e830d68372Patched SHA256:
51552670b4ffcf6ae17ecc2a69d7eaaa693b70bf4640b33ce14097fb665982a3Before-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.wavPipeWire 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/asoundpointer 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 invalidGENMASK(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.tplgCould 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.
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,4is SDW DMIC. So the impacted conf file should besdw-dmic-generic.confThe 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).
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....
@altger We have a fix candidate in #11258 . It is possible to build the binary tplg file yourself from source, but let me attach a version here (stable-v2.15 plus PR11258): sof-arl-cs42l43-l0.zip
- added a commit that references this issue
on Oct 5, 2026 @kv2019i Hi, thank you.
I just used the tplg you provided and confirm that it fixed the microphone issue. Moreover, yesterday I discovered that laptop internal speakers were affected and not working with my tplg (I'm not using them too often). And your tplg fixed that as well.- added a commit that references this issue
on Oct 6, 2026 SOF v2.15.1 tagged. Release binaries for all targets are available for testing in thesofproject/sof-bin#214 . ETA to merge and get a release out tomorrow (Wed).
- added a commit that references this issue
on Oct 7, 2026 Fix released in https://github.com/thesofproject/sof-bin/releases/tag/v2026.09.2
- added a commit that references this issue
on Oct 7, 2026 I confirm that the upstream repo package
sof-firmware 2026.09.2-1fixed the microphone issue. Thank you for your effort, great job.
System
sof-soundwire, ALSA card 0hw:0,4), CS42L43 over SoundWireintel/sof-ipc4-tplg/sof-arl-cs42l43-l0.tplgExpected 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
arecordfailsduring capture:
Both
hw:0,4andplughw:0,4produce the same read-time error.PipeWire recording is also affected: an approximately eight-second
pw-recordsession 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
For comparison:
Both reach recording and then fail at
pcm_read. The verbosehw:output reportsexact rate 48000 and accepted S16_LE stereo parameters.
Other observations
sof-soundwirecard 0,device 4 microphone.
cs42l43 Microphone Capture Switchason,on.Decimators 3/4 are on and feed DP1TX1/2.
no entries. Boot logs show the SOF firmware and topology loading.
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.