Skip to content

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

Closed
Closed
Dell Pro 14 Plus PB14250 (Core Ultra 7 255U, CS42L43): microphone hw:0,4 capture fails with pcm_read EIO#11271
Assignees
kv2019i
Labels
ARLApplies to Intel Arrow Lake platformbugSomething isn't working as expectedtopologyTopology issues

Description

@altger
altger
opened on Sep 30, 2026

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.

Activity

  1. altger commented on Sep 30, 2026

    @altger
    altger
    on Sep 30, 2026
    Author

    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

  2. charleskeepax commented on Oct 1, 2026

    @charleskeepax
    charleskeepax
    on Oct 1, 2026
    Contributor

    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: #11036

  3. bardliao commented on Oct 1, 2026

    @bardliao
    bardliao
    on Oct 1, 2026
    Collaborator

    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

  4. kv2019i commented on Oct 2, 2026

    @kv2019i
    kv2019i
    on Oct 2, 2026
    Collaborator

    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).

  5. kv2019i
    added
    bugSomething isn't working as expected
    topologyTopology issues
    ARLApplies to Intel Arrow Lake platform
    on Oct 2, 2026
  6. kv2019i
    self-assigned this
    on Oct 2, 2026

  7. kv2019i commented on Oct 2, 2026

    @kv2019i
    kv2019i
    on Oct 2, 2026
    Collaborator

    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....

  8. kv2019i commented on Oct 2, 2026

    @kv2019i
    kv2019i
    on Oct 2, 2026
    Collaborator

    @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

  9. kv2019i
    added a commit that references this issue on Oct 5, 2026

    topology2: sdw-dmic-generic: fix channel map/cfg regression

    ad9eb52

  10. altger commented on Oct 5, 2026

    @altger
    altger
    on Oct 5, 2026
    Author

    @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.

  11. kv2019i
    added a commit that references this issue on Oct 6, 2026

    topology2: sdw-dmic-generic: fix channel map/cfg regression

    d891942

  12. kv2019i commented on Oct 6, 2026

    @kv2019i
    kv2019i
    on Oct 6, 2026
    Collaborator

    Thank you @altger for quick testing! We'll fast path a 2.15.1 release to push this fix out ASAP. I'll move this to firmware component as this is now verified to be a topology problem.

  13. kv2019i
    transferred this issue fromthesofproject/linuxon Oct 6, 2026

  14. kv2019i commented on Oct 6, 2026

    @kv2019i
    kv2019i
    on Oct 6, 2026
    Collaborator

    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).

  15. kv2019i
    added a commit that references this issue on Oct 7, 2026

    v2.15.x: add sof-2.15.1 topology binaries for Intel targets

    fcd5ae8

  16. kv2019i commented on Oct 7, 2026

    @kv2019i
    kv2019i
    on Oct 7, 2026
    Collaborator

    Fix released in https://github.com/thesofproject/sof-bin/releases/tag/v2026.09.2

  17. kv2019i
    closed this as completedon Oct 7, 2026
  18. Hancock33
    added a commit that references this issue on Oct 7, 2026

    Updates on Oct 07, 2026 18:18

    0959a51

  19. altger commented on Oct 8, 2026

    @altger
    altger
    on Oct 8, 2026
    Author

    I confirm that the upstream repo package sof-firmware 2026.09.2-1 fixed the microphone issue. Thank you for your effort, great job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

ARLApplies to Intel Arrow Lake platformbugSomething isn't working as expectedtopologyTopology issues

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions