Good morning everyone. I would like to ask your opinion regarding a doubt of mine: is the audio conveyed via USB subject to error detection and control? In case of a damaged packet, is it recognized and resubmitted? I am not referring to dirverless DACs but to the use of WASAPI, ASIO or specific drivers for XMOS chipsets.
Google is your friend -
As far as i know, isochronous USB mode, which is used with audio, does not have error checking and does not retransmit packets.
Since google is not just a friend but a “great” friend, not only have I previously read the document you posted but many others including the claims of Chord UK in the person of Matt Bartlett and Rob Watts (who are not Trolls) claim that the its proprietary Windows driver allows you to resend lost packets (not samples).
Therefore USB audio Class 2 (driverless) does not allow for error correction. A proprietary driver (but also ASIO and WASAPI) allows this. However, I would like a concrete and definitive document on the issue. XMOS also produced some text but not so clearly spelled out:
Here we read:
“USB-Audio uses isochronous, interrupt and control transfer”.
Characteristics of the Interrupt Transfer mode are:
- Guaranteed Latency
- Stream Pipe - Unidirectional
- Error detection and next period retry.
Therefore, there is an error control and management. However, this is not entirely clear.
Just to say, USB Audio Class 2 is a much richer (and more complicated) protocol than 1.0. Audio Class 3 is from 2020, and I haven’t heard much about it yet.
Isochronous mode is used for transfer of audio samples. As you say, there is no error correction, though there is error detection (checksums) which would allow damaged packets to be dropped. Interrupt and control transfer are used for other purposes.
About “driverless” – there’s always a driver. Linux and MacOS have had USB Audio drivers “built-in” for years. Microsoft was, as usual, slow to step up, so many audio devices shipped with proprietary drivers for Windows computers. As of 2017, Windows contains built-in drivers for USB Audio. Some manufacturers still provide proprietary drivers that typically are for enhanced control functions of their equipment, sometimes because they haven’t yet gotten around to implementing USB Audio 2.0 which might make their proprietary drivers unnecessary.
1 Like
Which is a good reason to use a network connected “Roon Ready” endpoint.
The Pi and ALSA work really well for me. In a home environment and with a 3’ or so USB cable, I don’t worry about lost packets anyway.
2 Likes
Yes, realistically there isn’t going to be any packet loss on a 3 foot cable, but ethernet gives a nice output path display.