ASR is not (yet?) in the business of testing audio
systems. That is to say, holistically.
The measurements presented here are of a device-under-test, akin to a unit or module test in software.
IMO, it is neither fair nor useful to expect otherwise. However, I'm sure contributions to that effect would be welcomed.
@DDF, the problems you've discussed sound like OS scheduler problems.
It also sounds like you were/are saddled with equipment that is known to be problematic. Maybe only discovered after the fact, but still...
At some point, one might ask "what is my time worth?", and simply research and purchase more appropriate gear.
General purpose OS kernels are wondrously complex beasts!
All the more so considering they're expected to support the zoo of hardware they're interfaced with.
Audio is a soft real-time application: best-effort only, as there are no severe consequences to failure.
AFAIK, glitches have never caused a fatality
To compound this, isochronous usb transfers (audio) are not required to support re-tries upon error detection (CRC checksum failure).
Error correction is not a part of the protocol, although it could conceivably be tacked on (eg: Hamming ECC or similar) at the expense of extra bandwidth consumption and end-point complexity.