Guest Blog: It's Time to Admit that We Don't Know Everything
TAS reader and frequent AVGuide commenter ScottB submitted this piece, originally in response to a thread that developed around a USB cable review. I though he eloquently summarized a reasonable view of more broadly polarizing issues. This won't stop the food fight, but for those who actually want to think about what we know and how we know it, I thought it was a though-provoking read.
Here's Scott's piece:
Some relevant information about me: I'm an MSME who spent most of his career in software, culminating in 6 years as CTO of a F500 software company. I'm hardly a credulous subjectivist, either by training or by temperament. But a lot of the righteous certainty expressed (often hyperbolically) by the "objectivists" on this thread – and more generally, in this forum and others - is just plain fundamentalist ignorance, borne of oversimplification, misapplication of technical knowledge, and failure to think curiously and creatively.
The criticisms of the review fall into two camps that one often sees in other threads and comments: 1). You can't possibly have heard any differences, because it's impossible for cables to change the sound, and/or 2). the only valid way to determine audible differences is a double blind test (DBT).
Let's look at each of these in turn. First, as a number of posters have already pointed out, the USB audio protocol used by most DACs today is a synchronous protocol, very different from the packet-based protocols used to transmit data between a CPU and other types of peripherals. Synchronous digital transmission protocols, like SPDIF, AES, and synchronous USB, are transmitting both data and clock (timing) in the same analog-like waveform. Accurately recovering the data from that waveform is trivially simple compared with accurately recovering the timing. That is significant.
All digital audio systems exhibit some degree of timing error (aka jitter), which only becomes significant when the signal is transformed back to analog. Errors in timing of the data stream fed to the reconstruction filter(s) create distortion in the analog output. This distortion is enharmonic, and thus audible at much lower magnitudes than the harmonic distortion introduced by analog components and speakers. The magnitude of jitter-related distortion depends in a complex way on the characteristics of the jitter itself, as well as the encoded audio signal. None of this is controversial or unscientific; digital transmission jitter has been studied extensively, in both audio and other contexts.
Can cables impact jitter? Yes, in fact from the perspective of pure physics, it's impossible for a cable not to impact timing in a synchronous digital transmission system, because the signal itself is effectively like an analog waveform, containing very high frequency components. The interaction between the electrical characteristics of the cable, and the source and sink the cable is connected to, will change the shape of that waveform to some degree, and thus contribute to timing errors (jitter). How much those timing errors will impact the final analog signal depends in a very complex way on interactions between the cables, the transmitting and receiving circuits, the signal data itself, and the type and implementation of various clock recovery (de-jittering) schemes on the receiving end, but in general it is not possible to make a perfect de-jittering algorithm, and therefore not possible to make a synchronous digital transmission cable which will be perfectly "transparent" in the context of a complete system. So, in an absolute sense, the question of whether USB or SPDIF digital cables can impact the sound is pretty simple: of course they can. In fact, they almost must.
(BTW, for an object lesson in the dangers of oversimplifying systemic interactions between components, see the following set of measurements on speaker cables: http://www.audiodesignline.com/howto/showArticle.jhtml?articleID=201807390 in which the experimenters were shocked, shocked to find out that cables and amplifiers behave unexpectedly non-linearly when connected to a real load instead of a resistor).
OK, so yes, there can be differences in the analog audio signal resulting from "digital" cables. Are those differences audible? Well, that question can't be answered in general, because it's so dependent on both the specific system, and the listener. Here's where we get to that DBT part.
There is nothing wrong with applying DBT testing, per se, to audio equipment, just as long as we keep in mind what it is we are testing. Specifically, DBT testing as applied to music listening conflates four different tests into one test. If a double blind A/B/X test does not yield a statistically significant difference between A and B, at least these possibilities exist: 1). there are no differences in the physical sound between A and B, or 2). the differences in sound between A and B fall below the perceptual threshold of the test subject's hearing mechanism, or 3). A and B sound different at a level which could rise above the perceptual threshold, but the differences are obscured by the rest of the test environment (equipment, room, source content, etc), or 4). the differences between A and B rise above the perceptual threshold, but are not sufficiently recognized or remembered to enable the test subject to reliably identify the source.
All content, design, and layout are Copyright © 1999 - 2011 NextScreen. All Rights Reserved.
Reproduction in whole or part in any form or medium without specific written permission is prohibited.
Reproduction in whole or part in any form or medium without specific written permission is prohibited.
Comments
Very nicely written. Excellent post.
you. are. a . god.
Sheesh. If the current standards are that picky/difficult/prone to error, just use TCP/IP and ethernet and get it this paradigm-shift-from-analog-to-digital over with. You have described the whole SPDIF, AES, USB, DVI, HDMI, TosLink epoch as a bumpy road on the way to digital nirvana. Just get to the destination for god's sake. I'll be happy to run that weenie 48Mbit/sec Blu-Ray stream on 1000Mbit/sec ethernet, thank you very much. I think there is room in the bandwidth for timing information.
My post was originally written in the comments section of the Furutech USB cable review, and wasn't intended to address the question of reducing digital transmission jitter more broadly. The most logical way to address the issue of transmission-related jitter is simply not to transmit timing information over the transmission channel at all. In other words, use an asynchronous protocol, where the controlling clock is in the receiver, and data is transmitted "on demand" when needed to fill the input buffer - just as it is in Ethernet. Both Firewire and USB also support asynchronous, packet-based digital audio protocols, and a few USB DACs are starting to use USB in asynchronous mode. I have one myself - the Ayre QB-9. The async USB protocol is apparently quite involved to implement, but I suspect that, in about 2 to 3 years time, pretty much all USB DACs with audiophile pretensions will be using the asynchronous protocol.
BTW, Firewire, as I understand it, was async from the beginning, which goes a long way to explaining its popularity in professional audio gear.
MarcFirenze : HELL LETS GO FOR THE GOLD AND GO FOR 10GBoE!
But before we get there, We all might like to try Fiber channel 0r inifiniband to make sure we have enough headroom!
Well, Scott you have constructed a wonderful example without looking at all of the pieces of the puzzle.
At no point did you seem to argue that the data can't be reliably transferred over the cable. Your point was that jitter would affect how the data was utilized. In technical terms we call this the transport layer. In most communications protocols this is layer 1.
IF the output of the USB cable were directly coupled to the input of the DAC AND the DAC relied on exclusively on the clock derived from cable input you could potentially be right. Jitter would in fact be a significant contributer to the sound coming out of the DAC.
Which is precisely why designers DO NOT use a source clock from an outside source as a reference. The data transfer is actually transfered to the device at a rate which exceeds that rate required by the DAC and buffered locally in a memory and then used by the DAC controller at the rate which it requires.
The clock rate being fed to the DAC is derived from a local precision oscillator. If the DAC your using doesn't have this, well you get what you deserve and shouldn't wasting your money on cables, but on buying a better DAC.
In the end if the cable has adequate bandwidth to transport the signal, that is good enough. It's like saying the movie looked better at the theater becuase the film came on a truck instead of a plane.
As long as it wasn't damaged in shipment, it just isn't a relevant aspect of the discussion.
"Which is precisely why designers DO NOT use a source clock from an outside source as a reference. The data transfer is actually transfered to the device at a rate which exceeds that rate required by the DAC and buffered locally in a memory and then used by the DAC controller at the rate which it requires."
Incorrect, you haven't researched the fundamentals. You're making the same mistake that so many other posters on the USB cable review thread also made. What you're describing is an asynchronous protocol, in which the receiver requests data, at a high transfer rate, from the source, fills a buffer with the data, and begins to "meter" out the data from the buffer based on its own internal clock. When the data buffer gets more room, another request to the source is sent for more data. This is the kind of protocol used for almost all USB (or Ethernet, or eSata, etc) peripherals, like disk drives, printers, cameras, etc, and within broadly defined design limits, data integrity through these asynchronous protocols is perfect, regardless of cable.
But the most commonly used USB audio protocol is synchronous - the data is first clocked at the source, and transferred at the rate it is to be consumed, modulo clock error. The receiver has a passive role - it must take the data at the rate the source dishes it out. The receiver is therefore somewhat at the mercy of the source. Yes, the receiving DAC can buffer the input data and use its own clock to meter the data out of the buffer, and thus smooth timing errors. Almost all modern DACs do exactly that (typically called de-jittering). But the ability of a de-jittering system to eliminate timing error is finite. The input buffer can't be very big, lest the user interface become very slow. And obviously, the clock at the receiving end must in some way synchronize to the clock frequency being delivered from the source, or buffer overrun/underrun will occur. In other words, the receiver is not in complete control of its own clock, it must adapt to changes in the source clock, and those adaptations themselves are effectively timing "errors", aka jitter. And the source clock itself is modified by the interactions between source, receiver, and cable.
See my above comment about an emerging use of USB in asynchronous mode for digital audio, which obviously changes the above analysis almost completely.
If jitter is truly the cause of perceived differences between digital cables, why do NO manufactures state jitter rates and NO digital cable reviewers (in publications that do measurements) publish jitter measurements? The question of a digital cables impact on jitter could easily be answered by measuring jitter using a number of different cables in a known system. My guess is that such measurements are not done/published because they would reveal the digital cable market to be a fraud.
I agree with the meta-level point you're making, which is that cable manufacturers ought to provide a lot more credible theoretical and empirical information backing their claims. On the other hand, if you think that the very notion of cables impacting transmission jitter is a "fraud", there is plenty of empirical data showing the impact of cabling on jitter. Perhaps the most extreme example I've run across is an old article on CD transport jitter by Robert Harley, back when he was with that other mag:
http://www.stereophile.com/features/368/index3.html
In which RH saw a doubling of measured jitter just by reversing the direction of an SPDIF cable (!)
For those interested in a more in-depth treatment of the whole question of jitter, this article by Steve Nugent of Empirical Audio gets into more detail without being overly technical:
http://www.positive-feedback.com/Issue43/jitter.htm
I should also note that the whole idea of measuring jitter induced by a cable is problematic, since the impact of a cable is very dependent on the characteristics of the transmitter and receiver circuitry, and even the musical content itself. As you see in the Stereophile article above, you can find combinations of equipment and test signal that create gross differences, which may or may not correspond to performance in the average system.