Behringer WING usb audio - cyclic xruns dependent on periods/buffers

[Ben Bell]

I've got a Behringer WING digital mixer which is equipped with a USB
interface supporting 48 in, 48 out at 44.1 or 48kHz. It's plugged into a
USB3 interface and for the most part it seems to work well as a class-compliant
audio interface, but I'm struggling to eliminate xruns and it's starting to
feel either driver or hardware quirk related issue.

I've done all the usual things -- I'm running a PREEMPT_RT kernel, set up
the realtime priorities of Jack and the relevant USB IRQ to no avail. I'm
doing most of the debugging remotely over ssh with X shutdown and most
other processes on the system stopped. There's nothing plugged into the
computer beyond network, keyboard, mouse and the audio interface.

I'm currently testing on kernel 5.10.0-rc5 with preempt-rt patches, but I've
previously seen the same things on 5.4-rt (Debian backports) and 5.8
(self-compiled).

The xruns are characterised by bursts of "retire_capture_urb" warnings in
the kernel logs (and in particular the frame status for everything in those
URBs is EXDEV, meaning I think that the frames haven't been consumed by the
time it's retired). I've patched sound/driver/pcm.c to provide me with a bit
more debugging information and it looks like usually it's almost always
between 7-10 consecutive calls to retire_capture_urb that are affected.

The bursts of retire_capture_urb warnings seem roughly cyclic, with a
cycle time that is dependent on the combination of the frames/period setting
and the number of periods per buffer, though it doesn't appear to be a
strictly linear thing: 512/2 (~170s cycle); 256/2 (~94s); 128/3 (~65s);
64/13 (~270s). I can't immediately see any definitive smoking gun in the urb
or interrupt counts, but there is some grouping in the timings between
the xruns. Taking 64 frames, 5 periods, it's usually 50s, but sometimes 60s:

 21:47:57 50s since xrun 4 
 21:48:47 50s since xrun 5 
 21:49:46 59s since xrun 6 
 21:50:46 60s since xrun 7 
 21:51:36 50s since xrun 8 
 21:52:36 60s since xrun 9 
 21:53:36 60s since xrun 10 
 21:54:37 61s since xrun 11 
 21:55:27 50s since xrun 12 
 21:56:27 60s since xrun 13 
 21:57:27 60s since xrun 14 
 21:58:17 50s since xrun 15 
 21:59:16 59s since xrun 16 
 22:00:06 50s since xrun 17 
 22:00:56 50s since xrun 18 
 ...

If I count the URB numbers (sorry, I'm shaky on the terminology, but I'm
counting each URB which is retired) I often (but not always) see the same
number of URBs passing between xrun bursts. Currently at 64 frames/5
periods, it's often exactly 50042 or 49923 urbs between bursts.

The delay between starting Jack and encountering the first burst is not
predictable -- it's not just a whole cycle -- but stopping jack for e.g 30s
then starting again delays the next burst by the same amount. So it does seem
related to something in the audio streaming rather than anything else going on
on the system interfering. It's as if something is slowly slipping out of sync
between the Wing and the kernel until they need to resync, but I don't really
know enough about USB to have any deeper insight.

All the tests above happen to be at 44.1kHz with the Wing set to 48 in,
48 out, but changing to 48kHz or 2/2 IO doesn't seem to cure anything.

One more data point which may not be relevant: if I switch off or unplug
the Wing while Jack is running, the system gradually locks up over a period of
a few seconds. I can get something out of the console briefly afterwards but
within about ten seconds it's completely unresponsive. I imagine that pulling
out a USB device from a realtime thread isn't a kind thing to do, but I don't
recall this happening with other interfaces.

Any help or insights into where I should be looking (I'm a newbie in kernel
space) appreciated. If someone wants remote access to the box to investigate
in realtime we could probably figure something out.

bjb