RPi4 - Raspbian - TB causes huge number of IRQs


I’m running latest standard Raspbian (headless/minimal) on a Pi4.

Linux xxxxx 4.19.86-v7l+ #1283 SMP Fri Nov 29 18:37:40 GMT 2019 armv7l GNU/Linux

I’m running latest squeezelite (git-v1.9.6-1198) as audio streaming engine

I’m NOT using HW volume control.

As soon as I start squeezelite and it locks to the TB, the USB IRQs number are skyrocketing:

sec 1: 2191
sec 2: 2146
sec 3: 2152
sec 4: 2165
sec 5: 2144
sec 6: 2159
sec 7: 2165
sec 8: 2171
sec 9: 2152

As you can see more then 2000 IRQs per second are flooding the PI.
That looks extremely high to me.

Is this normal? Can you confirm this behavior?

FYI: Below the IRQ measurement snippet I wrote:

count=$(cat /proc/interrupts | grep xhci_hcd | awk ‘{print $2}’)
for i in {1…9}
sleep 1
countnew=$(cat /proc/interrupts | grep xhci_hcd | awk ‘{print $2}’)
echo “sec $i: $(($countnew - $count))”

why do you thing those happen because of the tb and not raspbian or squizlite ?

It’s directly related to the USB DAC. I think that’s obvious.
squeezelite or any other app is not working on such a low system level. BUT. Everything is possible. I’m not a designer (just an advanced user).
My wild unsubstantiated guess would be something is potentially wrong on the USB stack
(XMOS<>RPI firmware/drivers). I do know there have been issues/challenges on the isynchronous handshake in the past.

Most important. Other people should have a look and confirm this behavior.
Then you, as manufacturer should have a closer, look at it.

Thx for your support.


I also started a related thread on my home-turf:


There are indications that the high IRQ rate could in fact be related to the isynchronous USB mode.
The XMOS, as clock master, is basically causing all these interrupts.

The big Q is if the actual absolute IRQ amount is OK.
Or if a certain DAC firmware setting could lower that IRQ load.