Quote:
The key is the wording "
stored as binary electronic, magnetic, or optical signals...." But when this information - stored optically as "pits" and "lands" on CDs, or as electromagnetic 1s and 0s in computer files - is
transmitted via a cable, complete and instantaneous variation from one to zero or the reverse is physically impossible. Thus the signal is not a perfect square wave, but has a rise and fall time - i.e., it is analog. The receiver takes amplitudes above a "zero crossing" point as representing ones, and below that point as representing zeros. Thus even small variations in the signal can alter "zero crossing" times and show up as jitter. See for example page 3 of
http://pdfserv.maxim-ic.com/arpdf/AppNotes/3hfan402.pdf - "Jitter is essentially variation in the zero crossing times of the data eye."
Excellent basic verbal explanation!
And great pictures from the others. I second the note of the clock. And that's where USB tends to fall through the floor the worst...the host clock handling is brutal. A perfect world would not have USB audio, and Pro Tools would not have DR compression as an available option...
I have great respect for the "measurements" crowd and I mostly quietly snicker at the cable upgrader & placebo crowd, however there are moments that the measurements crowd is just as bad with myth and superstition as the cables crowd. Digital audio is one of them. The age-old "it's just ones and zeros, it can't go wrong, cables, and source "quality" don't matter unlike analog" that is regurgitated is a painful over-simplification of digital audio. The trouble with interference still exists though is greatly reduced, (or eliminated but replaced by other problems in the case of optical) and a whole host of timing and jitter problems that don't exist in analog get introduced. The word of the day regarding digital is "robust". The data contained in a digital signal is much more robust than an analog signal. But data can still be damaged or out of order on the receiving side, and an out of order packet is just a dropped packet that the DAC must "guess" at the replacement for.
The troubles with coax are the same as the troubles with analog coax: Interference, shielding issues, etc produce that nasty looking image seen above. The troubles with optical can be even worse. On paper its a great protocol, but imagine what the light looks like after being transmitted through optically imperfect refractive polymer tubes, then reviewed from an optically imperfect lens on the receiver. Plus whatever noise the LED diode may or may not generate on the analog reconstruction side. The plastics used in this stuff may be "optical" but for the price of a toslink receiver and cable, it's not exactly the same stuff used on the Hubble
All of that leads to that broken image above which gives a great idea of what a problem jitter is (thanks, Pyramid!) To explain that further: Which part of that messed up plateau marks the receipt of a sample? If part of the plateau is above the threshold and part isn't, which part is the sample....or is it two samples sent too fast? An imperfect clock will play with the wrong pacing (maybe too soon one one peak, too late on another peak, then too late again on the next which makes it sound normal, etc. Considering it's happening 44,100 times a second (on redbook), we can't hear the nanosecond hesitations or accelerations, but we can perceive something off about the sound, usually perceived as distortion or muddiness. A good clock will read exactly the same portion of the peak every time. But what if that portion of the plateau was the damaged part that dropped below threshold? Dropped a one. Alien interference (coax)? Added a one. In either case, you just altered the sample by a bit, and not in the linear way that analog gets distorted by by a random change in the sample. One bit won't turn James Taylor into Otis Taylor, but you get enough of these altered bytes and it affects the quality of the sound. USB adds the mess of a sloppy host clock and, cable pending, the potential for out of order packets, so you receive one sample before or after another. Thankfully they're numbered, so it won't start play in random order and sound like a bad acid trip at a Willie Nelson concert, but when the DAC sees a missing part of the sequence it just has to improvise. And when it finally GETS that missing packet, it has to throw it away because the time for that one already passed. Two errors for the price of one. So I can see where the dislike for USB comes from. But on a good implementation on a reliable cable, it works just fine.
