Disclaimer: I’m not a specialist on firmware and much less on hardware, so when I started having issues with the Framework sound card, I used an AI agent to help me debug the issue and find workarounds. It couldn’t solve my issue but at least it could make pavucontrol stop hanging whenever I had headphones plugged into the jack.
I thought the findings during the debug session could be valuable for someone else better-versed in this stuff, so I asked it to create a report of the stuff we did and what it points at in terms of causes. I tried to proof-read it as much as I could. I hope it helps future investigations.
Audio Expansion Card: the hang is WirePlumber stuck in uninterruptible sleep on a USB control transfer
I hit the clock source 9 is not valid failure on a Framework Laptop 16 today and traced the “audio apps freeze” part of it to a mechanism I haven’t seen named in this thread. It turns “audio randomly stops working” into something you can confirm in ten seconds, and it explains why the failure looks like PipeWire crashing when PipeWire is fine.
The mechanism
When the card fails to negotiate its clock source, WirePlumber blocks in uninterruptible kernel sleep (D state) inside usb_start_wait_urb — waiting on a USB control transfer that never completes. It stays there indefinitely.
That single fact explains the whole symptom cluster:
- PipeWire itself does not crash. No coredump, no signal, no
Failed with result in the journal. The pipewire and pipewire-pulse processes sit in a normal epoll_wait the entire time.
pw-cli works, pactl hangs. The PipeWire core is responsive, but the PulseAudio compatibility layer waits on session objects and default-sink metadata that WirePlumber creates — and WirePlumber never gets far enough to create them. So every PulseAudio client (pavucontrol, volume applets, browsers) hangs on connect while pw-cli info 0 answers instantly.systemctl --user restart wireplumber appears to hang. A D-state process can’t be killed until the kernel gives up on the URB. Mine took 23 seconds to stop, and the fresh WirePlumber immediately blocked again on the same device.
If you’re on this thread because audio “stopped working” and restarting PipeWire didn’t help, this is why. Richard’s observation in post 143 that “even a restart of the driver doesn’t seem to be able to do the trick” falls straight out of it — you cannot restart your way out of a process parked in D.
Confirming it
ps -o pid,stat,wchan:24,comm -C wireplumber
A healthy WirePlumber shows Ssl with poll_schedule_timeout. A wedged one shows:
PID STAT WCHAN COMMAND
1858 Dsl usb_start_wait_urb wireplumber
The pw-cli vs pactl asymmetry is the other quick tell:
pw-cli info 0 # answers instantly
timeout 5 pactl info # hangs
Recovery, without rebooting
Unplug the headphones. The card leaves the USB bus, which completes the stuck URB, and WirePlumber releases itself within seconds — same PID, no restart needed. Audio comes back on the internal speakers immediately.
This works because of the design behaviour documented in the “may not be detected unless headphones are plugged in” PSA: the card is only on the USB bus while the jack is occupied. Unplugging is a full USB disconnect, not just a jack event.
If you need the card gone while leaving headphones in, deauthorizing the device does the same thing:
echo 0 | sudo tee /sys/bus/usb/devices/<path>/authorized
Workaround that holds: keep the audio driver away from the card
Telling snd_usb_audio to skip the device stops the hang outright, because the driver never issues the transfer that blocks. In /etc/modprobe.d/:
options snd_usb_audio vid=0x32ac pid=0x0010 enable=0
Then reload (modprobe -r snd_usb_audio; modprobe snd_usb_audio) or reboot, and confirm it took by reading back /sys/module/snd_usb_audio/parameters/{vid,pid,enable} — expect 12972, 16, and N in the first slot.
The driver then declines the device explicitly:
usb 1-2.1: device (32ac:0010) is disabled
snd-usb-audio 1-2.1:1.0: probe with driver snd-usb-audio failed with error -2
Since applying it: no clock-source errors at all, WirePlumber never enters D, and PulseAudio clients stay responsive across jack inserts that previously hung them.
The cost is that the card stops being an audio device — this is a kill switch, not a repair, and it only makes sense if your card fails often enough that you’ve given up on it. Other USB audio devices should be unaffected, since they land on later array slots which keep enable=Y, though I haven’t verified that against a second USB audio device.
Log signature
The failure lands 5 to 6 seconds after a clean enumeration. Enumeration itself always succeeds — descriptors read fine, and the HID interface often attaches before the audio function fails:
Kernel log, one failing insert
usb 1-2.1: new high-speed USB device number 9 using xhci_hcd
usb 1-2.1: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
usb 1-2.1: Product: Audio Expansion Card
usb 1-2.1: Manufacturer: Framework
hid-generic 0003:32AC:0010.000A: input,hidraw8: USB HID v1.11 Device [Framework Audio Expansion Card]
usb 1-2.1: uac_clock_source_is_valid(): cannot get clock validity for id 9
usb 1-2.1: clock source 9 is not valid, cannot use
usb 1-2.1: 1:1: cannot get freq (v2/v3): err -110
usb 1-2.1: 1:1: cannot set freq 48000 (v2/v3): err -110
Once wedged, the three clock-source lines repeat every ~15 seconds indefinitely.
-110 is ETIMEDOUT — the device returns nothing at all, rather than rejecting the request. Errors shift to -71 (EPROTO) and -19 (ENODEV) as the device is torn off the bus.
The control-transfer failure is not specific to the ALSA path
With snd_usb_audio skipping the card entirely, usbhid still fails on a different interface of the same device:
usbhid 1-2.1:1.2: can't add hid device: -110
usbhid 1-2.1:1.2: probe with driver usbhid failed with error -110
Two independent drivers, two unrelated interfaces, the same ETIMEDOUT. So whatever goes wrong sits upstream of UAC2 handling — control transfers to the device stop completing, and sound/usb/clock.c is just where it usually gets noticed first.
Checking every insert across two boots, this HID failure turns out to be chronic and independent of the audio failure: it also appeared during the one session where audio negotiated correctly and played fine for fourteen minutes, six minutes into that working session. So the HID interface times out whether or not the audio function is healthy. That makes it useless as a predictor of the audio failure, but it does show the problem is broader than the clock-source path.
I want to be careful about what this does not show. It does not establish that the card itself is defective. Richard reports the same failure with other USB DACs rather than only the audio module, though those went through an expansion card in a bay — which removes “the audio card is uniquely at fault” without separating the card from the bay, the internal hub, or the port behind it. I will try a second USB DAC and report back.
What I ruled out
- USB autosuspend.
power/control was on for the device, so runtime PM never touched it.
- A software change. Same NixOS system generation for a week, kernel unchanged, and the failure appeared spontaneously well into an uptime with no reconfiguration.
- A single bad bay. It failed identically on two different expansion bays. Worth noting both bays land on the same internal GenesysLogic USB2.1 hub, so this rules out one bay’s contacts but not the internal hub.
What did not help
A full power-off produced exactly one clean insert, then the next insert 16 minutes later failed again with the identical signature. So a host power cycle is not a fix, and one clean insert after a reboot is not evidence of one.
Insert-by-insert for one day, counting only independent attempts (cascading re-enumerations of an already-wedged device excluded):
| Time |
Result |
| 08:58 |
failed |
| 09:11 / 09:12 (reseat, other bay) |
failed |
| 09:29 (after cold power-off) |
clean, stayed clean ~14 min |
| 09:45 |
failed |
| 09:50 – 09:52 (three attempts) |
all failed |
Roughly one clean insert in eight.
That lines up with John_Obscurant’s report of the rate climbing from about 1 in 5 boots to about 2 in 3 over a few days (post 160). This card worked normally until this morning.
On the iwlwifi power-save workaround
This machine cannot benefit from the iwlwifi.power_save=0 / iwlmvm.power_scheme=1 workaround discussed upthread (post 146), because its wifi is MediaTek and the Intel driver is not loaded at all:
wlp1s0 -> driver: mt7921e
iwlwifi loaded: 0
(no iwlwifi/iwlmvm parameters on the kernel command line)
The failure reproduces here anyway. That does not contradict the reports that those parameters help — Andrew_Moise saw a recurrence with them applied too — but it does mean iwlwifi power management cannot be the root cause, since the bug occurs on a machine where that driver is absent. If the parameters do reduce the failure rate on Intel machines, the mechanism is more likely something they change about platform power behaviour in general than anything wifi-specific.
Versions
|
|
| Machine |
Framework Laptop 16, Ryzen 7040 series |
| Card |
Audio Expansion Card, 32ac:0010, bcdDevice 0.02 |
| OS |
NixOS unstable (26.11.20260626) |
| Kernel |
7.1.1 |
| PipeWire |
1.6.5 |
| WirePlumber |
0.5.15 |
Kernel 7.1.1 is considerably newer than the versions in the Debian report (6.12 through 6.13.6) and in most posts here, and it reproduces exactly — so this is not fixed upstream.
Open questions
-
Has anyone tried the snd_usb_audio quirk flags (ignore_clock_source, get_sample_rate) instead of disabling the device? They change how the driver reacts to the failure, not whether the transfer times out, so I would expect them not to help — but I went straight to enable=0 rather than testing them.
-
Does anyone have a card that has never shown this? The hardware-versus-kernel question might be answerable by comparing bcdDevice between working and failing cards. It would also help to know whether your card logs usbhid ... -110 regardless of audio state, which would show whether that part is specific to my unit.
-
For those who saw improvement on a specific kernel (6.14.11 was mentioned), does the D-state block appear there too but resolve, or not appear at all? That distinguishes “device is slow” from “device is silent.”
I can reproduce this at will right now, which seems unusual for this issue — if there are diagnostics worth collecting, say which and I’ll post them.
