USB chipsets may matter.
I’m going to drop in here that USB chipsets used in the host appear to matter, possibly a lot, even (particularly?) in the USB 2.0 world. This may explain a lot of performance various people have seen in USB audio devices.
I did a bunch of research late last week into USB host behaviours and found that there are two underlying architectures, one of which (UHCI) uses the CPU to drive most of the work of running the bus (independent of things like transfer speeds) and one of which (OHCI) puts most of that work onto dedicated hardware in the card.
The result is that UHCI hosts (cards) put a lot more interrupts on the system bus, which for our purposes, is very bad. They also consume more CPU, though that’s not as big a factor I don’t think. Mostly, as linuxmusician tuning pages will tell you, you want to keep as many interrupts off your system bus as you can.
(There’s also a matter internally of synchronous NAK vs. asynchronous NAKs, and OHCI wins there too. The tldr if I understand it right is that OHCI can respond more quickly to packet failures; UHCI has to wait until the start of the next frame. Also, OCHI can queue multiple packets (n<4 I think? unclear) at a time, UHCI can queue only one at a time. But I am not that kind of hardware hacker and was gleaning what I could from the Linux USB driver mailing list and developer FAQ.)
I just moved from a UHCI Intel USB host card to an OHCI NEC USB chipset host card, system otherwise unchanged, and my minimum usable buffer setting dropped from 256 samples to 32 (3 frames in each case because USB), with buffer latency dropping from 30ms to 0.7ms, and actual measured round-trip Ardour latency dropping by an order of magnitude. On the UHCI cards (Intel chipset, VIA chipset, tried both) a setting of 128 samples would fail even just at playback, every time; on the OHCI card (NEC chipset), at a 32 sample buffer, I have now made a small number of successful test recordings against multitrack existing recordings, two channel input, without any XRUNs.
This is a big deal if you are running on USB 2.0 or 1.1, particularly on kit like the Presonus 1818vsl, where you don’t have access to hardware monitoring on Linux.
I talk about this more extensively here:
And before that, discuss OHCI and UHCI here:
(In USB 3.0, of course, chipsets on both ends matter, because the big deal with 3.0 isn’t so much the raw speed, though that’s nice; it’s that 3.0 is introducing FireWire-like data streaming. Before now, all USB data has been packeted; 3.0 provides a whole new transfer mode, apparently.)