I'd love to understand more about how USB audio is handled: packet sizes, is the ASIO buffer the only buffer etc. I was a very early audio designer for VoIP and had to work out the jitter buffers and handling packet loss from first principles, managing variable latency, priority flags & unscheduled interrupts etc. There's a precedent and a need but I'm definitely being greedy. I look at it as the same philosophy used in jitter rejection tests already conducted. These issues unfortunately aren't so uncommon (see the archimago post, or even from just today ) Injecting noise on the USB (conducted emissions) would be more a test of the DUTs ability to reject outside impairments than a real system test. Glitches may not be fatal but this PC had me on the ledge a few times.
To compound this, isochronous usb transfers (audio) are not required to support re-tries upon error detection (CRC checksum failure).Įrror 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.
General purpose OS kernels are wondrously complex beasts!Īll the more so considering they're expected to support the zoo of hardware they're interfaced with.Īudio is a soft real-time application: best-effort only, as there are no severe consequences to failure.ĪFAIK, glitches have never caused a fatality Maybe only discovered after the fact, but still.Īt some point, one might ask "what is my time worth?", and simply research and purchase more appropriate gear. It also sounds like you were/are saddled with equipment that is known to be problematic. However, I'm sure contributions to that effect would be the problems you've discussed sound like OS scheduler problems. IMO, it is neither fair nor useful to expect otherwise. The measurements presented here are of a device-under-test, akin to a unit or module test in software. ASR is not (yet?) in the business of testing audio systems.
0 kommentar(er)
