USB DAC produces audio dropouts and crackling when connected through a USB 3.0 bus-powered hub under CPU load on Linux laptop

Environment

Linux laptop (Ubuntu 22.04, kernel 5.15) using a bus-powered USB 3.0 hub to connect a class-compliant USB DAC (USB audio 2.0). Dropouts and crackling occur when CPU load increases (e.g., compiling or running heavy browser workloads). Direct connection to laptop USB-C port does not show issues.

Symptoms

Intermittent audio dropouts, crackling, and short bursts of silence in high-bitrate audio playback only when the DAC is connected to the bus-powered hub and the laptop is under CPU load. System audio overbuilt-in speakers unaffected. dmesg shows occasional 'usb 2-1: USB disconnect' and 'usb 2-1: reset high-speed USB device' entries near the time of audio glitches.

Observations

powertop shows autosuspend active for the USB hub and root USB controller. lsusb identifies the hub and DAC correctly. Timestamps in dmesg align with periods of sustained CPU usage; IRQ/softirq rates increase substantially during CPU heavy work. USB topology shows the hub on a single root port shared with other devices. Disabling pulseaudio resampling and using lower latency ALSA buffer parameters reduced but did not eliminate crackles. Connecting the DAC directly to a laptop USB-C port resolves the issue completely. Hub is bus-powered and sometimes shows nominal voltage drop under load (measured ~4.7V during peak).

Already attempted

Disabled USB autosuspend for the hub via udev rule and powertop; audio improved but occasional glitches persisted. Set higher priority for the audio process (rtprio) and reduced buffer size; paradoxically smaller buffers decreased latency but increased dropouts. Tried different hub and cables — a self-powered hub resolved the problem. Rebooted and upgraded kernel to latest stable; behavior persisted on bus-powered hubs.

Question

Is this primarily a power / USB bus bandwidth / host controller latency issue, and what reversible configuration changes can reliably diagnose whether the root cause is hub power, IRQ contention, or USB autosuspend? If it's a hardware limitation, what mitigations should be recommended to users?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Bus-powered hub unable to supply stable current to the DAC leading to hardware resets/noisy power during peak host activity. 90%

USB autosuspend or power management pathways spiking when CPU enters heavy activity, introducing transient device resets or reduced bandwidth. 60%

USB root hub controller IRQs and scheduling under high CPU/softirq load causing larger latency/jitter for isochronous endpoints. 50%

Summary

Symptoms and observations point to a combination of bus-powered hub power insufficiency and host controller latency/interrupt handling under CPU load. The hub's voltage sag under load and the disappearance of problems when using a self-powered hub or direct connection strongly indicate power/bus constraints. USB autosuspend and host controller interrupt load can exacerbate timing-sensitive isochronous audio streams, producing crackles.

Suggested Fixes

Diagnostic step 1

Confirm power hypothesis by connecting the DAC to a known self-powered hub or directly to a laptop USB-C port; if problem disappears, recommend using a self-powered hub as a mitigation.

Diagnostic step 2

Temporarily disable USB autosuspend for the hub and DAC (create udev rule to set power/control=on) and test under load; reversible by removing the udev rule.

Diagnostic step 3

Collect USB trace (usbmon) and dmesg during a reproducer to look for reset events and bandwidth/URB timing anomalies to provide to hardware vendor if needed.