Best jitter free USB DAC


Can anyone tell me which of the DACs with USB support have delt with the jitter problem described below?

I cannot decide between the Transporter, SB/DAC1/USB, SB/Brick/USB, SB/Lavry etc. I want to stay in the 2K range.

That is correct. Some of the USB-interface DACs I have measured have ridiculously high jitter. There is also the problem of ground-loops, that affects the performance.

Quote:

Could someone explain to me why this is the case? My understanding is that the USB interface protocol contains error correction and clocking mechanism just like the old serial interface did, whereas the sPDIF does not. So, theoretically, there should be NO jitter at all when going through the USB. What am I missing here?
QUOTE
You're missing the fact that as almost always implemented, the USB interface lacks a high-precision,local clock to control the remote DAC. This is because, again as almost always implemented, the DAC does not communicate back to the USB data source to control the flow of data.

As I understand it, the USB spec does include the possibility of implementing bidirectional communication so that the DAC clock can become the system master clock, but no-one has yet done that. If they do, the DAC clock can now be a high-precision VCXO rather than the usually sloppy PLL, with a significant reduction in jitter.

I'll try to find some references for you to study.

John Atkinson
Editor, Stereophile
dbk
You might take a look at the manufacturer's discussion for the Benchmark DAC1 USB which Benchmark claims "is nearly 100% jitter immune."

See:
http://www.benchmarkmedia.com/dac1/

and

http://www.benchmarkmedia.com/computer_audio/advanced_usb_audio.html
.
Steve at Empirical Audio claims converting a USB interface to an I2S virtually eliminates jitter. He performs this mod on the Benchmark DAC-1 and others. You might want to read his site for more info on this.
John - USB DAC's and USB to S/PDIF interfaces CAN have extremely low jitter, even lower than the best Transports, but implemetation and parts choices are critical. Jitter immunity claims must be taken with grain of salt IMO.

There are several ingredients that can achieve low levels of jitter in USB interfaces:

1) Low-noise power systems - not powered from the USB cable - USB interface preferably battery powered
2) Low-jitter clocks, such as Superclock4, Tent clock etc.. and installed properly
3) Optimum choice of USB converter chip - the TAS1020A and the TUSB3200 are the best current choices. The PCM270X series is not as good IMO.
4) Good design and parts selection in the Loop filter for the converter chip PLL
5) Proper treatment of transmission-lines, ie. termination and topology
6) Best selection of logic families and speed for fast, clean edges
7) Effective power decoupling to insure fast edge-rates on-die
8) Careful layout design that minimizes signal crosstalk and power-signal crosstalk
9) Careful USB interface termination and filtering

When all of these things are optimized, the jitter can be much lower than that from even the best Transport, but there will always be some jitter due to the clock from the PC affecting the PLL. The USB protocol that is commonly used for these interfaces, and that recommended by TI is what is known as "Synchronous-adaptive" or Isochronous. This protocol does not move the data on the USB interface in packets or in bursts, like a printer will. Instead, it reserves a USB channel and streams the data continuously without feedback packets to the PC. There is no error correction and no retry. For this reason, there is very little buffering in the USB interface device and the clock that is driving the USB from the PC is the one that ultimately clocks the D/A converter. It is really impossible to totally decouple from the PC clock, however there are some clever tricks that approach this, one of them being asynchronous upsampling, such as the AD1896 and the CS8421 do. This technique is used in the Benchmark DAC-1 USB and the BelCanto DAC3.

The difference between USB and a Transport is in the devices that TI has designed. They do a sort of "adaptive" digital PLL using an imbedded microprocessor. This allows the jitter in the PC clock to be highly decoupled from the clocks that emerge from the USB interface chip. Therefore, if the PLL filter is well designed and the base clock for the USB converter (usually 6MHz or 12MHz) is a low-jitter clock, then jitter in the clocks delivered to the D/A chip can be extremely low. The USB interface chip upscales this clock to 48MHz and then tracks the PC clock essentially in software. The clock that is generated from the digital PLL is actually quite sophisticated, behaving differently when the PC clock frequency is initially locking and then in a more narrow-band fashion after it finally locks. There is a paper from TI that you can read about their many tribulations designing this - email me for a link.

If you want to measure the jitter in a USB DAC or USB converter that has all of the ingredients listed above implemented in it, I can ship you one.

I also designed a device called a Pace-Car reclocker, which stores the serial data from a USB interface in a FIFO buffer and reclocks this out with a separate clock. Because the clock in USB is driven from the PC and not sourced at the USB interface, such a reclocker cannot be totally independent from the PC clock. The way this works is that the FIFO output clock is controlled to slowly move slightly higher and slightly lower in frequency to the originating PC clock, so that the FIFO does not overrun or underrun. Even though the frequency changes slightly every few seconds, the change is extremely small so the jitter is essentially only that of a Superclock4. This jitter is the lowest of anything USB that I have heard, and I have modified or studied most all USB DAC's and converters. The small frequency changes are inaudible.

Devices that use networking, such as the Sonus and Squeezebox are inherently superior because the clock at the receiver is truly independent from the PC clock. These, like all networked interfaces are packet-based and buffered at the receiving devices. It is much easier to FIFO buffer these streams and control the clock in the receiving device as a slave. Extremely low jitter interfaces can result from this, with the FIFO output clock being continuous running. The Pace Car that I designed can also buffer these streams.

Steve N.
Empirical Audio
Here is the link to the TI design saga:
http://www.planetanalog.com/showArticle.jhtml?articleID=12801995

Steve N.
Empirical Audio
So steve, which is the best sounding DAC of those listed...e.g.

Stello DA100 USB-D/A Converter
Benchmark DAC 1/USB
Transporter
Wavelength Brick/USB
Lavry DAC
Steve, are you suggesting then that the Transporter which uses a wireless network has the lowest jitter??
"Steve, how does the I2S fit into the above considerations?"

I2S is a means to keep the jitter low once you have a low-jitter signal. Creating S/PDIF again just adds jitter back in. Therefore, if you can stay I2S, the total jitter result will be lower. The Pace-Car for instance ONLY outputs I2S.
"So steve, which is the best sounding DAC of those listed...e.g.

Stello DA100 USB-D/A Converter
Benchmark DAC 1/USB
Transporter
Wavelength Brick/USB
Lavry DAC"

The Benchmark DAC-1 USB is the best sounding stock DAC in the list IMO due to the excellent firmware in the USB interface, with the Lavry as a close second provided it is driven from an Off-Ramp or similar low-jitter converter.
"Steve, are you suggesting then that the Transporter which uses a wireless network has the lowest jitter??"

No, I'm suggesting that the potential for lower jitter exists with these types of devices. It's all in the parts selection and the design implementation whether this is actually achieved.
Dbk,

The "Chime" also deals with the USB jitter problem in a similar fashion to the empirical. Both approaches do their best with proper layout, decoupling, and power supplies to generate a decent output from USB. They then go the extra mile and do a jitter-reducing reclocking with a VCXO for the output signals.

I believe the Empirical does this reclocking at the I2S outputs. The Chime does it right at the DAC chip.

jh