Columns Retired Columns & Blogs |
Loudspeakers Amplification | Digital Sources Analog Sources Featured | Accessories Music |
Columns Retired Columns & Blogs |
Loudspeakers Amplification Digital Sources | Analog Sources Accessories Featured | Music Columns Retired Columns | Show Reports | Features Latest News Community | Resources Subscriptions |
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.
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.
Thanks for the explanation, John. 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 sPDIF and its clocking issues. Another thing, how come no one made an Ethernet based transport / DAC combo?
Jim,
Thanks for the link. A very interesting read.
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.
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
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?
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
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.)
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
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
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.