I asked Bob Katz (
www.digido.com) whether FireWire contributed jitter
to a digital audio transfer. He asked me to post his reply to
rec.audio.pro.
Bruce Bartlett
Here is Bob's reply:
Digital interfaces do not contribute to audible problems UNLESS they
are driving the clocks which are driving the converters. This isn't
even possible in the case of Firewire since Firewire is clockless
(asynchronous). So if you think about it, Firewire is potentially even
better than SPDIF since it invites a circuit design with a master clock
in it. In the next edition of my book I'm going to stress the use of
the two terms "Synchronous interface" and "Asynchronous
interface". One difference between Firewire, SCSI, or Ethernet, for
example, versus SPDIF, AES/EBU, or MADI, for example, is that the
former three are Asynchronous, and the latter three are Synchronous. A
Synchronous interface contains an imbedded clock or works with a clock.
An asynchronous interface has no clock in it at all. So in reality,
there is NO JITTER to measure in the asynchronous interface; it's
impossible to measure or even have the concept of jitter. All it is
carrying is data. The data gets to the next place in line just fine.
Jitter only would happen or be measurable when the data is clocked out
at the other side. And even then it is not relevant unless that clock
is used to drive a converter. In a Firewire situation, as long as the
converters are being driven by a stable clock, then you have nothing to
worry about re jitter.
A similar question could be asked about Firewire video. You know that a
very stable clock is required to get a stable picture. So, how does it
work if Firewire doesn't have a clock in the line? Simple, the
crystal oscillator that drives the video is located in the circuitry
that drives the video, or in a PLL that is locked to external video.
The Firewire interface simply is a software interface with a very fast
data rate that has to be FASTER than the video or the audio requires,
so that you never run out of data on demand. The data is stored in a
small buffer and on the other side of that buffer, the crystal clock
feeds the devices that have to be clocked, e.g. Audio/video Converters
or video codecs.
I hope this helps!
Bob