View Single Post
  #16 (permalink)  
Old January 15th 11, 08:43 AM posted to uk.rec.audio
Don Pearce[_3_]
external usenet poster
 
Posts: 1,358
Default ASA and Russ Andrews again;!...

On Fri, 14 Jan 2011 17:13:42 +0000 (GMT), Jim Lesurf
wrote:

In article , Don Pearce
wrote:
On Fri, 14 Jan 2011 09:57:44 -0500, "Arny Krueger"
wrote:


"Don Pearce" wrote in message


And of course the term jitter is used with cables - wrongly in my
view. Jitter is a random perturbation of the data edges caused by
noise events. The inaccuracies caused by cables are systematic and
identical on each data edge. This means that they can be corrected.
Either matching the cable better or using channel estimation (all
mobile phones have this and it is dirt cheap) to measure and cancel
the inaccuracies that shift the edges out of place.

The digital signal's edges tend to wander around because the cable is
ultimately a low pass filter and the spectral content of the digital
data passing through the cable varies as the data varies. So matching
the cable better can't be of much help.

No, this simply isn't so. Matching a cable properly results in a flat
frequency response and a flat group delay. This reshapes the signal
perfectly.


Not if the cable loss changes with frequency. You can optimise by playing
with the matching, but not necessarily get a perfect output.

Over the kinds of frequency we are dealing with in audio, cables are
sensibly flat regards loss. Sure there will still be errors, but of
minuscule magnitude. I don't think I've ever seen a cable that wasn't
good for hundreds of MHz if used properly.

That leaves the more complex methods like channel estimation or
buffering and reclocking.


More complex, sure, but not exactly taxing these days.


It is true that the bandwidths involved aren't exactly out into the THz
region. But as Arny has said, it makes sense in practice to get the dac
(receiver) to deal with this by some mix of reclocking, bufferring, etc.
That way the results become less dependent on the choice of source and
cable... and if someone has bent or stood on the coax. :-)

As I said also - my first point about buffering and generating a clean
clock rather than using the data edges.

d