Critical Bug Report: Severe Kernel Interrupt Storm & Overheating (Pi Zero 2 W & Pi 3B) due to ASL 3 USB Audio Polling

AllStarLink
1

Dear AllStarLink Development Team,

I am writing to report a severe performance and thermal issue we have diagnosed in the latest AllStarLink (ASL 3) update regarding USB audio handling with the CM108 sound device.

We run custom ASL nodes, and after upgrading to the latest version, we noticed massive CPU overheating on both our Raspberry Pi Zero 2 W and Raspberry Pi 3B units, along with system hangs (90-second systemd Stop Job timeouts) during shutdown/reboot.

After extensive kernel-level debugging, we isolated the root cause to the new ALSA/ASL audio driver architecture.

System Environment:

  • Hardware: Raspberry Pi Zero 2 W and Raspberry Pi 3B
  • USB Devices: CM108 USB Audio Device + SL2.1 USB Hub (fixed on PCB)
  • OS: Debian 12 Bookworm based (Linux 6.18.x)
  • Software: ASL 3

Issue Description & Root Cause:
In older versions (ASL 1.x / 2.x), the USB audio stream was dynamically suspended during standby. The CM108 LED would be solid/slow blinking, and the system rested at 0% load.

In the new ASL 3 update, the "always-on" audio architecture (presumably for zero-latency / anti-clipping) forces continuous polling and keeps the stream permanently open, sending silent data constantly. The CM108 LED now blinks rapidly 24/7.

This continuous stream forces the USB bus into a severe hardware loop, generating 20,000 to 25,000 interrupts per second (in value in vmstat 1), along with ~10,000 context switches per second.
This 20k/sec interrupt storm pushes the processors of both the Pi Zero 2 W and the Pi 3B to their absolute limits just handling the hardware interrupts, causing severe overheating on both devices without showing high user-space CPU load in htop.

Diagnostics Performed:

  1. Applied dwc_otg.speed=1 — Reduced interrupts to ~10k/sec, but didn't stop the loop.
  2. Applied dwc_otg.fiq_fsm_enable=0 — Worsened the condition; IRQs spiked to 25k/sec.
  3. A/B Testing on Pi 3B (Direct CM108, No Hub): Replicated the exact same 20,000+ interrupts/sec and the identical overheating issue. This proved the SL2.1 hub is not the root cause; the software's continuous polling is forcing the hardware loop across different Pi models.
  4. sysfs unbind test (Pi Zero 2 W): Ran echo '1-1' | sudo tee /sys/bus/usb/drivers/usb/unbind after stopping Asterisk. Interrupts instantly dropped to ~5,000/sec, CPU idle time hit 99%, and overheating stopped immediately.

Feature Request / Suggestion:
We understand the need for zero-latency audio for certain setups, but this "always-on" architecture is breaking compatibility and causing massive interrupt overhead and severe thermal issues on devices like the Pi Zero 2 W and Pi 3B.

Could you please consider adding a configuration option (perhaps in simpleusb.conf or a kernel quirk) to re-enable "Dynamic Stream Suspend" during idle times, similar to older ASL versions?

Looking forward to your thoughts on this. Thank you for your continued hard work on the AllStarLink project!

Best regards,
[ S21DBA ]
[ [email protected] ]

2

The interrupt rate matches what you measured. On a Pi 3 Model B Plus running kernel 6.18.39, with Asterisk holding a C-Media USB audio device open in both directions, vmstat sat at about 19,000–24,000 interrupts/sec and roughly 6,000–14,000 context switches/sec. Most of that is dwc_otg_sim-fiq (about 12,400/sec) plus the dwc_otg USB interrupt (about 3,100/sec). The ARM timer accounts for the other ~5,000/sec, which lines up with the rate you still saw after unbinding USB.

This board is not showing the thermal side of it. It is idle in the mid-90s, the SoC is at 37°C, and it is not throttling. Same interrupt pattern, without the overheating you saw on the Zero 2 W and the 3B.

The capture and playback streams are both left running, so the CM108 stays in an always-open full-speed transfer. That is the loop your tests pointed at.

3

Let's keep discussions on this in the issue so we're all looking at the same data.