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
