i have a simple query. i use a chord mojo dac connected to my imac. i’ve read that core audio in roon is bit perfect with macs and i also use exclusive and integer mode. i also know that mac driverless usb does not send back any faulty usb data packets should they arise in the same way that windows computers do. in windows therefore you are assured of bit perfect playback. can someone explain how mac driverless usb is therefore still bit perfect with core audio in roon? for the chord mojo i use you download a seperate driver for windows.
Hi Mohab,
the drivers (whether manually installed or automatic) are no guarantee of bit perfect audio. What the drivers offer is a direct path to the hardware, so that some software CAN provide bit perfect audio to your USB DAC.
The USB Audio protocol is not packet based like, say, TCP over IP. It does not do ReSend, regardless of OS.
Atb Mike
Strictly speaking, the USB audio protocol is packet-based (as opposed to a continuous stream) as is all USB traffic. The hardware can detect errored packets and in the case of USB audio normally discards them. As you said, the USB audio class specification does not call for re-transmission of errored packets.
All UAC 1.0 and 2.0 audio transfers happen in isochronous mode. While bad packets can be detected and dropped, there isn’t bandwidth allocated for resending them (or, generally, time available to do so) so they are not resent.
This is true on both Mac + Windows–there is no platform distinction as you’re implying. Also, there is no such thing as “driverless usb”. All “driverless” means is that a driver came with the OS instead of from the device vendor. There are not extra technical implications associated with being “driverless” in general.
If a packet is corrupted and dropped, you will hear a dropout. This is a catastrophic failure in the context of USB Audio–and unrelated to the idea of whether or not the playback chain is “bit perfect”.
The “lossless” designation in Roon serves as a confirmation that the playback chain is designed in a way that does not change the bits. It is not a guarantee that no component in the chain will ever experience a catastrophic failure–no-one can guarantee that for you.
Likewise: you wouldn’t consider a power outage during playback to impede the “bit perfect” nature of the playback chain either. Nor would you consider it a failure to be bit-perfect if someone accidentally yanked the USB plug out. These situations are other overt failures, just like dropouts. They don’t create subtle quality degradation–if they happen, you will know that the system is not working.
I would caution about using this form of intuition.
Being packet based and doing resends are orthogonal concepts.
USB audio is packet based and provides error detection but not error correction.
TCP/IP is stream based. It makes guarantees and decisions about resending content at the stream level, not the packet level. Meaning–a TCP receiver can say “I have received the stream up to packet 99” but cannot say “packets 100 and 107 are missing”. Subtle distinction, but important.
There are packet based network protocols that implement error detection/correction at the packet level. AirPlay is one example.
Best to just think about these concepts separately and avoid tying them together. Pretty much every permutation one could imagine exists somewhere.
