I understand the following key differences between isochronous and asychronous:
Isochronous/synchronous protocols guarantee bandwidth availability at the cost of reliable transmission
Asynchronous systems will guarantee uncorrupted data
But if I have an Asynchronous USB Dac being fed over an Isochronous network (between the USB Dac and the host computer) will the Async USB Dac guarantee uncorrupted data, even with isochronous protocols are being used in the chain?
The chain to give some context:
PC is Roon Core with music stored locally > PS Audio LANRover over the network (Isochronous) > Asynchronous USB Dac
Obviously the Asynchronous USB Dac connected directly to the PC would ensure uncorrupted data but does the PS Audio LANRover (which is isochronous but is not asynchronous) compromise the guarantee of uncorrupted data?
My Roon Core can only see my Asynchronous USB Dac (as seen in the signal path). It can’t see what’s happening along the way (ie going through my isochronous PS Audio LANRover over the network).
So, does the isochronous LANRover compromise RAAT’s asynchronous protocol and hence compromise my asynchronous USB DAC’s guaranteed uncorruped data?
Just looking for brief answers @brian without going too much into it, if it’s even possible to explain something like this simply
Excuse me jumping in here, and I hope I don’t say anything that conflicts with any future replies…but maybe some quick comments might be helpful.
The terminology used for USB audio is confusing, and I think you might have somewhat fallen victim to it.
Isochronous refers to the way data to be transmitted on USB are carved up into chunks and scheduled for transmission on the bus. As you said, the aim of the isochronous transmission is to guarantee bandwidth on the bus.
In the context of USB audio device, “asynchronous” is used to mean that the USB peripheral (e.g. DAC) is effectively in charge of the sample clock. More specifically it means that the sample rate is not directly referenced to the USB master clock generated by the host. As far as I know it has nothing to do with guaranteeing data integrity as such, but rather that there is no loss of samples due to differences in clock rates on the host and peripheral.
USB DACs tend to use isochronous transfers but with asynchronous sample clock management. In other words, there is no inherent conflict between those terms. That should be the case for your DAC whether it’s connected directly to your PC or via the LANRover (I’d guess).
The DAC will be able to detect errors in incoming data by virtue of the CRC attached to each USB packet it receives, but if errors occur there usually isn’t a recovery mechanism (at least, I don’t recall the USB audio class specification defining one). That’s true of isochronous transfers and is not dependent on the asynchronous sample rate management.
For Roon specifics (and any corrections) best wait for the gurus…
As I understand it, in order for a device to have a USB output, it needs some internal USB controller, and its from that controller and the data it sends that asynchronous USB is improved over synchronous (with the help of the DACs re-clocking). What happens before and after in the chain will not affect this benefit.
Yep someone told me in another forum that USB 2.0 requires the asynchronous feedback feature and this product (based on the ICRON product linked above) complies with USB 2.0 spec, according to the product spec anyway.
So by default it has to include the asynchronous feedback feature too, at both the USB transmitter end and the receiver end.
Hope I understood what he was telling me correctly.
Again, unfortunately, there is potential for confusion here between the USB Audio Device class specification v2.0, which is what defines the asynchronous sample rate management, and the USB specification v2.0 (usually called just USB 2.0). Looking at the spec for the ICRON product you linked to it refers to USB 2.0 but I didn’t see any reference specifically to USB Audio Device class 2.0. That doesn’t necessarily mean it won’t work as expected, though.
Ian, thanks again for the further clarification. I may actually ask the manufacturer, just out of curiosity and for learning purposes because I’m interested in this stuff (sad I know). Mainly in understanding the gear I own !
