USB Interface Perfect?- Computer Audio

[fmak]

There is a guy in Audioaylum who states (without supporting explanation) repeatedly that USB interfaces are perfect and cannot introduce errors eg in an external CDRWs.

I have found evidence that this DOES and that the same CDRW mounted on PCI and thru' and NEC USB to PCI Bridge introduces many REad/Write errors as detected by Exact Audio Copy. The two also sound very different with the USB device much worse.

What have you found and what do you think? There seems to be quite a fixation with USB audio in some quarters.

[MWP]

Well USB is only a data bus... the data it moves is packet based, so it doesnt have strict timing rules.
Because of this, USB data transfers should always be perfect.

If your having problems i would sugest its due to a poor hardware implementation or dodgy drivers.

[Ulas]

Contrary to popular belief, USB digital audio is not perfect and not jitter free. All USB devices that meet the class definition for audio devices use the isochronous data transfer protocol.

Isochronous transfers do not support data retransmission in response to errors on the bus. A receiver can determine that a transmission error occurred. The low-level USB protocol does not allow handshakes to be returned to the transmitter of an isochronous pipe. Normally, handshakes would be returned to tell the transmitter whether a packet was successfully received or not. For isochronous transfers, timeliness is more important than correctness/retransmission, and, given the low error rates expected on the bus, the protocol is optimized by assuming transfers normally succeed. Isochronous receivers can determine whether they missed data during a (micro)frame. Also, a receiver can determine how much data was lost. Section 5.12 describes these USB mechanisms in more detail.

An endpoint for isochronous transfers never halts because there is no handshake to report a halt condition. Errors are reported as status associated with the IRP for an isochronous transfer, but the isochronous pipe is not halted in an error case. If an error is detected, the host continues to process the data associated with the next (micro)frame of the transfer. Only limited error detection is possible because the protocol for isochronous transactions does not allow per-transaction handshakes.
(source: USB Specification Revision 2.0)

There are no packets in the usual networking sense of the word. Instead, every millisecond the host sends 1 millisecond worth of audio samples in a single burst. The receiver buffers the data and adjusts its sample frequency generator to output the samples received over the next millisecond. In case of data or reception error, there is 1 millisecond of silence.

USB phase jitter is limited to +/- 1 audio sample.
(source: USB Device Class Definition for Audio Devices Release 1.0)

[00940]

USB audio transfer is certainly not perfect. Apogee uses an AD1896 combined with a TUSB3200 on the USB daughterboard for the mini-dac to reduce the jitter. And the new perreaux usb dac uses the src4193 to clean its usb flow. The guys from Grace Design promised us to get the jitter of a TI PCM2902. They use it in their new M902 but also use a special PLL to get rid of jitter. They claim the output is bit-perfect though. Isochronous transfer is certainly not jitter free and isn't the graal we're after.

However, the external usb cdrom should run in burst mode with buffers to clean the mess and should be ok. If the buffer is sufficient and the drivers well done. Guess it's not the case with your external player.


Here is "the" classical article about isochronous usb transfer :
http://www.planetanalog.com/showArti...cleID=12801995