Wow. This bug has been rocking for almost 1.5 years now. Children are already talking at this age 
Here are some screenshots from Windows. I’ve somehow managed to connect a mouse and use the on-screen keyboard. Yes, the keyboard (i2c?) and the entire USB stack are dead.
most recent drivers&bios&etc
Thank you, kind sir! Fiddling with random BIOS setting indeed helps.
The problem (same dmesg errors etc) in scope came out of the blue. It was working fine for many weeks since I bought the audio module, then it stopped this morning. The laptop (fw16) was lying around without battery power for whole weekend, the only thing I recall doing is that I disconnected and rearranged expansion ports, without waking up the laptop.
Experiencing this on a Framework Desktop (not Laptop 16), Ubuntu with kernel 6.17.0-20-generic.
Was in a Slack meeting with headphones connected to the Audio Expansion Card. Audio was working fine for ~8 minutes, then it went silent and the device vanished from audio settings. Replugging headphones had no effect.
Kernel logs show the exact failure cascade:
08:16:55 — Card connected normally (32ac:0010, device #4)
08:24:37 — usb_set_interface failed (-110) ← ETIMEDOUT, first trigger
08:24:42 — USB disconnect, device #4
08:24:44 — Card auto-reconnected (device #5)
08:24:48 — Immediate disconnect — clock source 9 invalid, err -71 (EPROTO)
08:24:51 — Card auto-reconnected again (device #6)
08:26:00 — Final disconnect after ~1.5 min of repeated clock negotiation failures
The repeating error loop before each disconnect: uac_clock_source_is_valid(): cannot get clock validity for id 9 clock source 9 is not valid, cannot use cannot set freq 48000 (v2/v3): err -71
After the final disconnect, the card was completely gone from lsusb. WirePlumber also logged can't open control for card hw:3: No such file or directory.
Tried a software USB hub reset (echo 0/1 > /sys/bus/usb/devices/3-2/authorized), the Genesys Logic hub re-authorized but the card did not re-enumerate. Physical reseat of the expansion card was needed to recover.
Confirms this isn’t limited to Laptop 16, the Desktop is affected too on 6.17.
Makes sense. The desktop is essentially the same hardware as the Laptop 16, so there’s likely a lot of overlap on the firmware/bios end of things. I’m disappointed in the lack of response on the github issue since this does seem to be a pretty broad issue that’s hard for an end-user to debug
Hi, I’ve just ran into this (or similar issue) today. This is what happened in journalctl -f after plugging the audio jack in (21:15:36) and pulling it out (21:15:42). I’m running NixOS 25.11 on FW 16 AMD 7480
kvě 10 21:15:36 framework kernel: usb 1-1: new high-speed USB device number 11 using xhci_hcd
kvě 10 21:15:36 framework kernel: usb 1-1: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
kvě 10 21:15:36 framework kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kvě 10 21:15:36 framework kernel: usb 1-1: Product: Audio Expansion Card
kvě 10 21:15:36 framework kernel: usb 1-1: Manufacturer: Framework
kvě 10 21:15:36 framework kernel: ucsi_acpi USBC000:00: unknown error 256
kvě 10 21:15:36 framework kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-1/1-1:1.2/0003:32AC:0010.0014/input/input31
kvě 10 21:15:36 framework kernel: hid-generic 0003:32AC:0010.0014: input,hidraw14: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-1/input2
kvě 10 21:15:36 framework mtp-probe[70830]: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-1"
kvě 10 21:15:36 framework mtp-probe[70830]: bus: 1, device: 11 was not an MTP device
kvě 10 21:15:36 framework Discord[6848]: [6848:0510/211536.727734:ERROR:media/audio/pulse/pulse_util.cc:385] pa_operation is nullptr. [repeated 8x]
kvě 10 21:15:36 framework mtp-probe[70858]: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-1"
kvě 10 21:15:36 framework mtp-probe[70858]: bus: 1, device: 11 was not an MTP device
kvě 10 21:15:36 framework kded6[2643]: Failed to notify "Created too many similar notifications in quick succession"
kvě 10 21:15:42 framework kernel: usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
kvě 10 21:15:42 framework kernel: usb 1-1: clock source 9 is not valid, cannot use
kvě 10 21:15:42 framework kernel: usb 1-1: USB disconnect, device number 11
kvě 10 21:15:42 framework fwupd[3425]: 19:15:42.793 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-1: failed to setup: failed to get firmware version info: failed to get GET_REPORT: failed to GetReport: USB error: Operation timed out [-7]
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot get freq (v2/v3): err -71
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
kvě 10 21:15:42 framework kernel: usb 1-1: clock source 9 is not valid, cannot use
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot get freq (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
kvě 10 21:15:42 framework kernel: usb 1-1: clock source 9 is not valid, cannot use
kvě 10 21:15:42 framework wireplumber[65396]: spa.alsa: Error opening low-level control device 'hw:2': No such file or directory
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot get freq (v2/v3): err -19
kvě 10 21:15:42 framework wireplumber[65396]: spa.alsa: can't open control for card hw:2: No such file or directory
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
kvě 10 21:15:42 framework kernel: usb 1-1: clock source 9 is not valid, cannot use
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot get freq (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
kvě 10 21:15:42 framework kernel: usb 1-1: clock source 9 is not valid, cannot use
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot get freq (v2/v3): err -19
kvě 10 21:15:42 framework kernel: usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -19
kvě 10 21:15:42 framework kded6[2643]: Failed to notify "Created too many similar notifications in quick succession"
I am experiencing this as well; I have in the past, sometimes it goes away for a while only to reappear. I’m running Ubuntu 25.10 with kernel 6.17.0-29-generic, latest firmware (0.0.4.4 per the ‘Firmware Updater’ app); I’ve experienced this over a variety of firmware and kernel versions.
sudo dmesg -w gives:
[17299.156170] usb 1-2.3: new high-speed USB device number 20 using xhci_hcd
[17299.278096] usb 1-2.3: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
[17299.278123] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[17299.278127] usb 1-2.3: Product: Audio Expansion Card
[17299.278156] usb 1-2.3: Manufacturer: Framework
[17299.659771] input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb1/1-2/1-2.3/1-2.3:1.3/0003:32AC:0010.0011/input/input29
[17299.710409] hid-generic 0003:32AC:0010.0011: input,hidraw6: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c5:00.3-2.3/input3
[17304.896391] usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
[17304.896413] usb 1-2.3: clock source 9 is not valid, cannot use
[17310.016324] usb 1-2.3: 1:1: cannot get freq (v2/v3): err -110
[17315.136321] usb 1-2.3: 1:1: cannot set freq 48000 (v2/v3): err -110
[17320.257372] usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
[17320.257381] usb 1-2.3: clock source 9 is not valid, cannot use
[17325.376425] usb 1-2.3: 1:1: cannot get freq (v2/v3): err -110
[17325.376434] usbhid 1-2.3:1.3: can't add hid device: -110
[17325.376474] usbhid 1-2.3:1.3: probe with driver usbhid failed with error -110
[17330.496594] usb 1-2.3: 1:1: cannot set freq 48000 (v2/v3): err -110
[17335.617532] usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
[17335.617538] usb 1-2.3: clock source 9 is not valid, cannot use
journalctl -f gives
May 17 22:12:01 ram kernel: usb 1-2.3: new high-speed USB device number 20 using xhci_hcd
May 17 22:12:01 ram kernel: usb 1-2.3: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
May 17 22:12:01 ram kernel: usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 17 22:12:01 ram kernel: usb 1-2.3: Product: Audio Expansion Card
May 17 22:12:01 ram kernel: usb 1-2.3: Manufacturer: Framework
May 17 22:12:01 ram kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb1/1-2/1-2.3/1-2.3:1.3/0003:32AC:0010.0011/input/input29
May 17 22:12:01 ram kernel: hid-generic 0003:32AC:0010.0011: input,hidraw6: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c5:00.3-2.3/input3
May 17 22:12:01 ram mtp-probe[137623]: checking bus 1, device 20: "/sys/devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb1/1-2/1-2.3"
May 17 22:12:01 ram mtp-probe[137623]: bus: 1, device: 20 was not an MTP device
May 17 22:12:01 ram boltd[2206]: probing: started [1000]
May 17 22:12:01 ram gnome-shell[7965]: Could not open device /dev/input/event17: Could not get device info for path /dev/input/event17: No such file or directory
May 17 22:12:01 ram mtp-probe[137659]: checking bus 1, device 20: "/sys/devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb1/1-2/1-2.3"
May 17 22:12:01 ram mtp-probe[137659]: bus: 1, device: 20 was not an MTP device
May 17 22:12:04 ram boltd[2206]: probing: timeout, done: [2974688] (2000000)
May 17 22:12:07 ram kernel: usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
May 17 22:12:07 ram kernel: usb 1-2.3: clock source 9 is not valid, cannot use
May 17 22:12:12 ram kernel: usb 1-2.3: 1:1: cannot get freq (v2/v3): err -110
May 17 22:12:17 ram kernel: usb 1-2.3: 1:1: cannot set freq 48000 (v2/v3): err -110
May 17 22:12:22 ram kernel: usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
May 17 22:12:22 ram kernel: usb 1-2.3: clock source 9 is not valid, cannot use
May 17 22:12:27 ram fwupd[31025]: 21:12:27.502 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb1/1-2/1-2.3: failed to setup: failed to get firmware version info: failed to get GET_REPORT: failed to GetReport: USB error: Operation timed out [-7]
May 17 22:12:27 ram kernel: usb 1-2.3: 1:1: cannot get freq (v2/v3): err -110
May 17 22:12:27 ram kernel: usbhid 1-2.3:1.3: can't add hid device: -110
May 17 22:12:27 ram kernel: usbhid 1-2.3:1.3: probe with driver usbhid failed with error -110
May 17 22:12:32 ram kernel: usb 1-2.3: 1:1: cannot set freq 48000 (v2/v3): err -110
May 17 22:12:37 ram kernel: usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
(essentially the same contents in both).
For comparison, I also have a USB-C to audio adaptor that I bought along with a phone that had no headphone jack. When I plug that in, I get,
demsg -w:
[17691.301887] ucsi_acpi USBC000:00: unknown error 256
[17691.675222] usb 7-1: new full-speed USB device number 5 using xhci_hcd
[17691.862420] usb 7-1: New USB device found, idVendor=18d1, idProduct=5025, bcdDevice=23.20
[17691.862428] usb 7-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[17691.862431] usb 7-1: Product: USB-C to 3.5mm-Headphone Adapter
[17691.862434] usb 7-1: Manufacturer: Google
[17691.862436] usb 7-1: SerialNumber: FLK71002052020A7A504335
[17692.776038] input: Google USB-C to 3.5mm-Headphone Adapter as /devices/pci0000:00/0000:00:08.3/0000:c7:00.4/usb7/7-1/7-1:1.3/0003:18D1:5025.0013/input/input31
[17692.826363] hid-generic 0003:18D1:5025.0013: input,hidraw6: USB HID v1.11 Device [Google USB-C to 3.5mm-Headphone Adapter] on usb-0000:c7:00.4-1/input3
journalctl -f:
May 17 22:18:33 ram kernel: ucsi_acpi USBC000:00: unknown error 256
May 17 22:18:33 ram kernel: usb 7-1: new full-speed USB device number 5 using xhci_hcd
May 17 22:18:33 ram kernel: usb 7-1: New USB device found, idVendor=18d1, idProduct=5025, bcdDevice=23.20
May 17 22:18:33 ram kernel: usb 7-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
May 17 22:18:33 ram kernel: usb 7-1: Product: USB-C to 3.5mm-Headphone Adapter
May 17 22:18:33 ram kernel: usb 7-1: Manufacturer: Google
May 17 22:18:33 ram kernel: usb 7-1: SerialNumber: FLK71002052020A7A504335
May 17 22:18:34 ram kernel: input: Google USB-C to 3.5mm-Headphone Adapter as /devices/pci0000:00/0000:00:08.3/0000:c7:00.4/usb7/7-1/7-1:1.3/0003:18D1:5025.0013/input/input31
May 17 22:18:34 ram kernel: hid-generic 0003:18D1:5025.0013: input,hidraw6: USB HID v1.11 Device [Google USB-C to 3.5mm-Headphone Adapter] on usb-0000:c7:00.4-1/input3
May 17 22:18:34 ram mtp-probe[141555]: checking bus 7, device 5: "/sys/devices/pci0000:00/0000:00:08.3/0000:c7:00.4/usb7/7-1"
May 17 22:18:34 ram mtp-probe[141555]: bus: 7, device: 5 was not an MTP device
May 17 22:18:34 ram boltd[2206]: probing: started [1000]
May 17 22:18:35 ram mtp-probe[141593]: checking bus 7, device 5: "/sys/devices/pci0000:00/0000:00:08.3/0000:c7:00.4/usb7/7-1"
May 17 22:18:35 ram mtp-probe[141593]: bus: 7, device: 5 was not an MTP device
May 17 22:18:37 ram signal-desktop_signal-desktop.desktop[141611]: [141611:0517/221837.585892:ERROR:services/video_capture/video_capture_service_impl.cc:201] Bind context provider failed.
May 17 22:18:37 ram boltd[2206]: probing: timeout, done: [2962286] (2000000)
May 17 22:18:54 ram auditd[1686]: Audit daemon rotating log files
and that one works as expected - so the sound system as such is still working, but Framework’s Audio Expansion Card has these issues.
I’ve posted in the github page, but for anyone else coming here:
Effects:
Tests that I ran:
Also, the Meze Audio headphones plugged into the FW13 jack also worked.
So it seems to be limited to the removable audio module when using headphones (not earphones) on Linux.
This has happened to me as well.
On startup it will work, then after 10 minutes to an hour it will disconnect. Re seating doesn’t fix it, has to be a complete restart of my desktop
It started happening to me too, a few weeks ago (Xubuntu 24.04). What is weird is that it’s completely random. I could have it work a whole week and crash just once after it, or crash 3 times in a day.
I switched to an other usb/jack adapter in the meantime. I hope we will be able to have a fix soon 
.
Just a quick followup to my previous posts. I spent some time debugging this and observed a very specific phy/routing behavior:
Audio deadlocks are avoidable by changing slots: Like many, my Audio Expansion Card used to randomly drop, throwing err -110 timeouts and locking ALSA and requiring a cold reboot. And on Windows too. I physically moved the Audio Card to a different slot and it has been stable for over 2 months now.
The root cause seems to be phy/slot specific, rather than a global hub crash:
Right now, my mouse dongle is in the “troublesome” slot where the audio used to be. It randomly drops. Looking at dmesg, these USB resets somwhow correlate with Wi-Fi power state changes.
More than that lsusb shows that both the stable Audio Card and the dropping mouse dongle are routed through the exact same internal gl3590 hub.
Because the Audio Card doesnt drop anymore, it seems like the gl3590 chip itself is NOT browning out or resetting. If the hub crashed globally i would expect both devices to drop and my kernel to deadlock again.
I am not a mainboard expert, and without probing this with proper lab equipment, i cannot definitively prove it. However i believe this indicates that the wifi di/dt transient is affecting specific physical slots or traces. When the wifi module wakes up it may be causing a localized voltage droop on that specific slots power switch or, perhaps, inducing EMI directly onto the usb d+/d- traces routed to that area. The port loses sync and drops the dongle.
Luckily a mouse is a stateless hid, so unplugging/plugging it back recovers it (unlike audio).
Interesting find that this helped for you. This was one of the first things I tried for this issue, it didn’t change anything for me. It seems the issue is a lot more complex.
It randomly drops.
I do sometimes see such drops even for the keyboard module as far as I understand it also registers as a USB device, with sometimes having some input hiccups. So it might as well be a more general USB issue. But over the past few weeks (possibly since upgrading BIOS to 4.04) I’ve noticed the touchpad module dropping out relatively frequently, while the keyboard kept working. I’d have to look out for those dmesg entries but I’ve yet to notice any WiFi power state changes around that time.
Okay, I just found this, looks at a quick glance-over like I have exactly this problem.
It’s not super exciting that it’s been around since Jan 2025 without a solution, but also, if switching the audio expansion card to a different slot might work around it, I might not have to care. I will do that and report results (it does seem like upgrading firmware 03.07 → 04.04 made it happen way less often; it’s happened one time in the week since I upgraded when it used to be a “happens 0-2 times per day every day” thing).
Yeah, doesn’t work in a different slot, either. Failed almost immediately – maybe the reason it got a lot less flaky after the firmware upgrade was just that I had switched it to a less-failure-prone slot at about the same time.
Jul 20 16:17:55 kitchen kernel: Bluetooth: RFCOMM TTY layer initialized
Jul 20 16:17:55 kitchen kernel: Bluetooth: RFCOMM socket layer initialized
Jul 20 16:17:55 kitchen kernel: Bluetooth: RFCOMM ver 1.11
Jul 20 16:18:35 kitchen kernel: usb 1-4.1: reset full-speed USB device number 9 using xhci_hcd
Jul 20 16:19:58 kitchen kernel: warning: `ThreadPoolForeg' uses wireless extensions which will stop working for W>
Jul 20 16:31:59 kitchen kernel: clocksource: Watchdog remote CPU 4 read timed out
Jul 20 17:40:03 kitchen kernel: SCSI subsystem initialized
Jul 20 17:40:03 kitchen kernel: block nvme0n1: No UUID available providing old NGUID
Jul 20 17:40:29 kitchen kernel: usbhid 1-2.1:1.2: can't add hid device: -110
Jul 20 17:40:29 kitchen kernel: usbhid 1-2.1:1.2: probe with driver usbhid failed with error -110
Jul 20 17:40:30 kitchen kernel: hid-generic 0003:32AC:0002.0010: hiddev96,hidraw0: USB HID v1.11 Device [Framewor>
Jul 20 18:01:04 kitchen kernel: usb 1-4.1: reset full-speed USB device number 9 using xhci_hcd
Jul 20 18:06:37 kitchen kernel: usb 1-4.1: reset full-speed USB device number 9 using xhci_hcd
Jul 20 18:06:42 kitchen kernel: usb 1-2.1: 1:0: usb_set_interface failed (-110)
That’s since the bottom of the boot (finishing up initializing network and Bluetooth), and then playing music successfully for a little while, and then the 18:01 I think roughly corresponds to when I tried to start up some new music and it failed (and then is apparently wedged now until the next reboot). I shouldn’t have said anything about the new firmware improving things.
That was my thought as well. I made the update just like two weeks ago as it was said that 4.04 isn’t really that important for most users. It first looked like it was better, but no, it happend twice since.
I’ve now checked. For me at least the last occurrence didn’t correlate with any Wi-Fi power changes, but rather with a graphics driver issue (more or less):
Jul 18 12:27:05 kernel: RIP: 0010:dcn31_program_compbuf_size+0xd0/0x220 [amdgpu]
Jul 18 12:27:05 kernel: ? drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x1b0/0x3d0 [drm]
Jul 18 12:28:54 systemd[1]: sys-devices-pci0000:00-0000:00:08.1-0000:c1:00.1-sound-card0-controlC0.device: Failed to enqueue SYSTEMD_WANTS job, ignoring: Transaction for sound.target/start is destructive (shutdown.target has 'start' job queued, but 'stop' is included in transaction).
Yes, there is a almost 2 min gap, but it might be some timeout after which the kernel gave up. But that only happened this one time.
It is interesting that for some of you the issue seems to appear during use of the laptop. I never had it happen once the system was sucessfully booted with working expansion card. For me it is always either that a) after booting the expansion card does not work at all or b) it works after booting and stays the same until complete shutdown. Recently, I got used to suspending the system instead of shutting down, which makes the problem appear less often for me and I only see it once a week or so when rebooting for a kernel update.
There were very rare (~ 1/month) occasions where the system did not come back up after a suspend which might be related - apparently there are some commands sent to the audio expansion card (and blocking) before the screen lights up, so the system appears locked, but still reacts to Alt+SysRQ commands. But there might also be a different reason, there is nothing suspicious in the journal …
Recently, I got used to suspending the system instead of shutting down, which makes the problem appear less often for me
That’s wild – for me it was the exact opposite. For a while my FW16 was completely stable as long as I didn’t suspend and resume (shut down and restart every time), and always kept it plugged in.
I’m currently running with power management completely disabled on the network card, just to investigate that theory about where the flakiness is coming from. I have that and a couple other things to try and if any of them make it stay stable for a couple of weeks I’ll definitely be back in touch.
I’ve had powersave on my wifi card disabled for quite some time now for other reasons, but if memory serves I set it up as a connection-specific carveout rather than fully disabling it. Either way it didn’t seem to have any effect on the audio failure rate, but another datapoint can’t hurt. Best of luck
Not sure if I already tried that or someone else did, but I’m testing right now if disabling USB power saving (usbcore.autosuspend=-1 in kernel) changes anything. After all, unless the occurrence takes down the entire Linux audio stack, mostly audio that goes through USB is affected, and the logs do show USB errors. So who knows.
Yeah, for me it seems very specifically connected with audio through the headphone expansion card. (Although, yes, when it happens it kills audio systemwide, it seems like that is maybe just collateral damage from the expansion slot having issues).