just wanted to understand RAAT protocols for playing to a DAC via USB… specifically, for a Roon Tested DAC running asynchronously and connected directly to a transport running ROCK.
i assume RAAT is sending data according to the USB specification which calls for the inclusion of cyclic redundancy checksums (CRC) in USB packets. so, the receiver should be able to detect errors occurring during transmission. question is, does the DAC drop packets with errors and send retransmission requests to the sender in a RAAT environment?
RAAT is immaterial here. Ultimately its sending to a audio class-compliant USB function. The checksum occurs in the USB layer, and it’s up to the higher layer protocol (e.g., audio class) to handle retransmits if CRC errors are detected. I can’t find if the audio class does any retransmission, or simply drops the bad frames, however. The USB documents are all locked behind partner paywall. RAAT likely doesn’t even get told about the CRC errors.
If I recall correctly, the USB audio class specifications do not require retransmits if CRC errors are detected. Typically the USB controller hardware checks incoming frames for CRC errors and will report the error to the USB controller driver. So it will depend on the device driver whether anything above it gets to hear about the occurrence of the CRC error.
it is my understanding that there are three types of USB data transfer, each with its own error correction protocols and consequent latency:
isochronous transfer: CRC error detection, no retry or guarantee of delivery… guaranteed latency
interrupt transfer: CRC error detection, next period retry… bounded latency
bulk transfer: CRC error detection, guarantee of delivery… no minimum latency
so, wouldn’t error correction also depend upon the type of transfer being done? and, i assume RAAT is able to (directly or indirectly) specify which transfer type to execute?
thus, for a DAC running asynchronously where RAAT fills the DAC buffer as requested, it would seem error correction would either be attempted or guaranteed?
Incorrect. RAAT is using the USB Audio Class. That determines the mode, which is isochronous, as already stated. RAAT has no control over this; its a USB standards thing.
thanks for the replies! …just looking to understand how all the available connection / transmission options (s/pdif, usb, ethernet) work in a RAAT environment.