Quote:
In the April Issue, a followup review of the Grace Design m902, John Atkinson states that he has found USB interface on many DACs to contain greater amount of jitter than the S/PDIF interfaces.

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?

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

Steve Nugent

This link is very informative. The deadly "jitter-bug" continues to rear is ugly head.

Quote:
I'm surprised that no one has included a high precision clock with an USB DAC. I would have thought that would be the first thing anyone would do since USB gives the manufacturers the freedom from the awful S/PDIF and its clocking issues.

Unless the DAC has control over how fast the source sends data, it it has to have a local clock that can adjust itself over a relatively wide range, so that its word-clock frequency is equal to the long-term average of the incoming data. That way, its local FIFO buffer will neither empty nor overflow. Such a local clock will not have the highest precision/stability.

Quote:
how come no one made an Ethernet based transport / DAC combo?

There are several Ethernet/WiFi-connected DACs: Apple Airport Express, Slim Devices Squeezebox, Sonos ZD80. You have the same clocking problems that exist with USB in that the data are being sent asynchronously, though 2-way communication is now a given. I don't know if the DACS in these devices control the data source, but the measured jitter rejection of the Squeezebox and AE is not that good.

John Atkinson
Editor, Stereophile

Quote:
Steve Nugent

This link is very informative. The deadly "jitter-bug" continues to rear is ugly head.

Thanks Jim. I think it was Ted that I had a conversation with about the USB operating modes at CES in January.

John Atkinson
Editor, Stereophile

Wavelength's Brick was reviewed (a VERY positive review) but not measured, and Steve Nugent's USB devices haven't yet been reviewed. Any chance on this happening in the near future?

Quote:

Quote:
Unless the DAC has control over how fast the source sends data, it it has to have a local clock that can adjust itself over a relatively wide range, so that its word-clock frequency is equal to the long-term average of the incoming data. That way, its local FIFO buffer will neither empty nor overflow. Such a local clock will not have the highest precision/stability.

A question from a dummy. Why is jitter such an issue over transmission media? Another way of asking this question - if my data network at work can send data in the gigabits/second range without data loss due to jitter, why is jitter between components apparently such an issue with very low speed data, i.e. audio? Surely the audio data can be transmitted with *zero* loss over any medium (Ethernet, USB, wireless etc), and simply buffered and reconstructed with a high precision clock in the DAC?

The answer to your question is obliquely referred to in the text of mine that you quoted. Yes, you can clock the audio data out of a local RAM buffer with a crystal-controlled, high-precision clock. However, without the DAC being able to communicate back to the data source when it wants more data -- and the way USB DACS are almost always implemented prevents such communication -- any difference between the local word-clock frequency and the long-term average of the incoming data (given that it is packetized), will result in the RAM buffer catastrophically emptying or overflowing. The easiest way to eliminate this is simply to use a larger buffer memory. However, you then have the problem of "latency" to deal with, ie, it takes a relatively long time after you start sending data before you hear it.

In the worst case, where you have, say, a data buffer equal to half the size of the longest musical work you want to stream, a CD's worth, you will need a 350MB buffer which will take a couple of minutes to fill even at a USB2.0 transmission rate.

What appears to be done is to use a local clock with a wide variation window, and such a clock is always going to have relatively high jitter.

John Atkinson
Editor, Stereophile

Quote:
in principle, buffer + re-clock will remove *all* jitter from a transmission link.

Only if the buffer is large enough so that there need be no causal link between the output data word-clock and the average of the incoming data. Otherwise, any jitter in the clock will only be low-pass-filtered, not eliminated. And as I said, a large enough buffer to eliminate the need for a causal link suffers from an unacceptable latency problem. (You press <play> but the music doesn't start for possibly several minutes.)

Quote:
If we assume that (i) the source will supply data at a long-term average at or close to 44.1kHz and (ii) the clock in the source won't be out by more than [say] a percent or two, the buffer shouldn't have to be very large at all, even if the DAC can't talk back to the source?

It needs to be very close, if you do the math for a typical buffer of a few MB. Looking through your posts, you seem to be looking at this subject from the viewpoint of a digital engineer, when you talk about bits being lost or not lost. The levels of word-clock jitter being discussed are orders of magnitude below those required to give rise to data errors. However, they still give rise to potentially audible artefacts in the DAC's analog output.

If you read the literature, you will find that for an audio DAC's analog output not to be polluted by jitter on the word-clock controlling the conversion, that jitter needs to below a couple of hundred picoseconds in a 16-bit system even when there are zero data errors. For a 24-bit system, if I remember correctly, you need jitter to be below around 20ps.

John Atkinson
Editor, Stereophile

Quote:
I don't know if the DACS in these devices control the data source, but the measured jitter rejection of the Squeezebox and AE is not that good.

John,

Have you published the measurements for Squeezebox 3 jitter rejection? I couldn't find, but it would be really interesting to see them.

My understanding is that Slim Devices people somehow managed to deal with latency issues while having very large buffer in the device. I haven't noticed any delay in starting playback, but someone turned off his PC and SB continued to play for about 90 sec after that. Generally you don't have to fill the buffer completely to start read from it.

As for USB, one knowledgeable person and Audio Asylum mentioned lack of audio chips that support asynchronous USB, so that might be a reason for absence of DACs supporting this mode.

Has there been any recent developments on USB DACs? I'm waiting for a jitter free DAC with USB.

Gang,

Sorry for the delay... Alex just asked for clarification today.

John, much of the jitter I have found in the common USB IC's comes from the clock generator based on the chip. Most of these have to both generate the required USB clocks and the Audio frequencies.

In general you can use ASYNC mode for USB where the endpoint (dac in this case) generates a signal to the computer to send packets at a predefined rate determined by enumeration. Enumeration is the sequence applied when connected that an enpoint (be it a dac, drive, mouse, ad/da, ipod whatever) tells the PC what it can do. For example.. the dac may say it is a 16 bit type and can handle 32, 44.1, 48k, 88.2 and 96k data rates. Or it can say 24 bits with the same. Or in one case that I designed 44.1K/16 ONLY. At this point the dac would also say if it is ISO or ASYNC.

ISO it the most common USB Audio stream in that the computer sends down a packet with data and in the header says the speed and data format and the data for that sample.

In ASYNC mode where the dac controls the speed. The dac actually has 2 endpoints. One is too send the a control packet to the host computer asking for more data and the other is the input endpoint which receives the data.

After enumeration the computer sends down control information saying what rate the dac is going to handle and so forth. This is one of the good things about USB is that the host computer will tell it. I am running 16/44.1 or 16/48 etc... that way you can change internal working of the dac to prepare for the new interface.

But just being ASYNC isn't enough to get rid of jitter. First off most of the newer USB 2.0 host controllers have ISO built in so there is less overheard associated with delivering the data to the dac. In the case of ASYNC the host processor is interrupted each time the dac needs data. Windows users will have to wait for Vista for ASYNC mode to even work.

There are presently some USB chips that are better than others. Many of the original USB chips tried to emulate their SPDIF receivers and these have excessive jitter. The second generation parts where much better but some included dacs which corrupted the clocking and still shared the USB clock with the audio clock and these frequencies are not even close to each other. The third are highly programmable parts which seperate the two clocks and offer more options and therefore lower jitter.

The good thing about USB is that the clock is not carried on top of the data. So the receiver does not have to seperate them. Also USB is good because it tells the computer what it can and cannot do and therefore set's guidelines for proper use. The bad thing about USB and SPDIF is the fact that money needs to be made by the company supplying these and that is where the engineers in all of us have to get the most out of it to make all of you happy.

If you have any questions about USB audio I am always glad to answer them.

Thanks
Gordon

Quote:
Has there been any recent developments on USB DACs? I'm waiting for a jitter free DAC with USB.

This is a very important topic. Does anyone have advice on which USB DACs are currently or are likely to be implemented in a way to minimise this problem (besides the fine work at Wavelength)?

Benchmark has just introduced a DAC1 with USB. They assert that they can transfer files with resolution greater than 16/48 via USB. See their website for more info.