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

But how much jitter is in the Microsoft Excel spreadsheet I have stored
on my local ATA hard drive!!?!?!?

Cheers,
Trevor de Clercq

brubart wrote:
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

I researched some stuff about that a while back, and I believe what you're
saying is not quite true.

Firewire is, in fact isochronous, not asynchronous, and some audio interfaces
might try to play back the audio signal at the speed the data is received.
There is definitely some jitter possible in this case. To do it right, each
interface should incorporate a short buffer and a phase locked loop to match
its clock to the average rate of the data stream while producing jitter-free
output.

Digital mixers with Firewire inputs (e.g. mLAN), which employ SRCs to record
from different unsynchronized digital inputs must also employ buffers and PLLs
to avoid converting the jitter in the Firewire signal into jitter in the
encoded audio data itself.

I'm no expert, but this is what I was lead to understand when I last read up
on the subject.

On 17 Feb 2005 06:03:17 -0800, "brubart" wrote:

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

In article .com writes:

I asked Bob Katz (www.digido.com) whether FireWire contributed jitter
to a digital audio transfer.
Here is Bob's reply:

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

Another way of looking at it is that the "bus" interfaces aren't audio
interfaces at all - the interface is on the other end of the pipe, and
that's where the jitter is introduced. Once the audio is in digital
form, how it actually gets to the workings of the program that plays
it (in this case Firewire) doesn't matter.

You might have as well asked if the PCI bus (how an "in the computer"
card is usually connected) causes jitter. You probably never thought
about that, did you? g


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

Steve Jorgensen wrote:
I researched some stuff about that a while back, and I believe what you're
saying is not quite true.

Firewire is, in fact isochronous, not asynchronous, and some audio interfaces
might try to play back the audio signal at the speed the data is received.
There is definitely some jitter possible in this case. To do it right, each
interface should incorporate a short buffer and a phase locked loop to match
its clock to the average rate of the data stream while producing jitter-free
output.

Digital mixers with Firewire inputs (e.g. mLAN), which employ SRCs to record
from different unsynchronized digital inputs must also employ buffers and PLLs
to avoid converting the jitter in the Firewire signal into jitter in the
encoded audio data itself.

I'm no expert, but this is what I was lead to understand when I last read up
on the subject.


just my two cents..

As far as I know FireWire is a (computer) data interface. There
basically is no relation between its data rate and the rate that is
necessary for a 'real time' audio reproduction at the other end of the
digital chain.
Where you talk about isochronous I guess it is on the data interface
level. That your data happens to be related to audio has nothing to do
with the FireWire interface.


My regards

Bert Kraaijpoel

Mike Rivers wrote:
In article .com
writes:

I asked Bob Katz (www.digido.com) whether FireWire contributed
jitter
to a digital audio transfer.
Here is Bob's reply:

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

Another way of looking at it is that the "bus" interfaces aren't
audio
interfaces at all - the interface is on the other end of the pipe,
and
that's where the jitter is introduced. Once the audio is in digital
form, how it actually gets to the workings of the program that plays
it (in this case Firewire) doesn't matter.

You might have as well asked if the PCI bus (how an "in the computer"
card is usually connected) causes jitter. You probably never thought
about that, did you? g



Well there is a difference.

The device that presents the audio i.e the device with the D/A
converter must somehow be synchronized with the device that playsback
the data. If there is no synvhronization, and the playback spped is not
the same as the presentation speed, then eventually some buffer
someplace will either underfloe or overflow.

Inside a PC, the audio card asks for data from the HD so in a sense
they get synchd.
True, the data is sent in large busrts at rates tht have nothing to do
with the audio and there is no issuse of the HD causing jitte rin the
D/A converter.

I guess if the presentation device has a hugh buffer like a HD, the
data can be sent over at whatever fast rate it can and it is all stored
on th elocal HD then played back and presented as needed.

But if you don't have this large buffer then some sort of coordination
is needed.

But I agree, that because of these buffers, jitter in terms of audio
distortion is not an issue. But in terms of buffer overflow/underflow,
there needs to be some sort of coordination unless a very large buffer
like a HD is avaialbe.

Mark

"Mark" wrote in message
oups.com...
But I agree, that because of these buffers, jitter in terms of audio
distortion is not an issue. But in terms of buffer overflow/underflow,
there needs to be some sort of coordination unless a very large buffer
like a HD is avaialbe.

There is coordination - the device at the receiving end tells the device at
the sending end when it's ready for more data. It works fine as long as the
pipe between the two is fast enough and the devices are responsive enough.

Sean

In article .com writes:

The device that presents the audio i.e the device with the D/A
converter must somehow be synchronized with the device that playsback
the data.

Why? If I record something today and play it back tomorrow, how can
they possibly be synchronized? When it comes to monitoring while
tracking, everything can be played from the same clock. With several
milliseconds of latency, there's plenty of time for picosecond slop.

But if you don't have this large buffer then some sort of coordination
is needed.

But you do.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

"Steve Jorgensen" wrote in message

I researched some stuff about that a while back, and I believe what
you're saying is not quite true.

Firewire is, in fact isochronous, not asynchronous, and some audio
interfaces might try to play back the audio signal at the speed the
data is received. There is definitely some jitter possible in this
case. To do it right, each interface should incorporate a short
buffer and a phase locked loop to match its clock to the average rate
of the data stream while producing jitter-free output.

Digital mixers with Firewire inputs (e.g. mLAN), which employ SRCs to
record from different unsynchronized digital inputs must also employ
buffers and PLLs to avoid converting the jitter in the Firewire
signal into jitter in the encoded audio data itself.

I beleive that the more correct statement is that Firewire (like USB) can be
isosynchronous, or not.

"Mike Rivers" wrote in message
news:znr1108691609k@trad
In article .com
writes:

The device that presents the audio i.e the device with the D/A
converter must somehow be synchronized with the device that playsback
the data.

Why?

Because if you run out of data, or process the data too slowly, you tend to
get these nasty tics and pops.

If I record something today and play it back tomorrow, how can
they possibly be synchronized?

They need to happen at the same rates, but you're right the recorded event
and the played back event aren't truely in synch.

In this case we're talking synching the DAC to some more-or-less independent
source, like a computer.

When it comes to monitoring while
tracking, everything can be played from the same clock. With several
milliseconds of latency, there's plenty of time for picosecond slop.

...and DACs are effectively slaved to the clock of the SP/DIF or AES/EBU
source.

But if you don't have this large buffer then some sort of
coordination is needed.

Agreed. With protocols like Firewire and USB, there should be some kind of
pacing so that the DAC doesn't get flooded with data, or run out of data.

Mark said
The device that presents the audio i.e the device with the D/A
converter must somehow be synchronized with the device that playsback
the data. If there is no synvhronization, and the playback spped is not
the same as the presentation speed,

firewire is just the tranportation used by the computer to feed the
data hungry conversion process.
fire wire is not a device presenting audio
fire wire is a protocol for computers
developed by a company for use in handling audio/video data.
yamaha liked it and they have developed
mlan as a sub protocol of firewire
both are built into OS X 3
usb is not the same type of protocol
it was developed for printers and mice.

jitter is intoduced within the electronics handling the steaming of
this data to the converters.
AES/EBU standards (SP/DIF) were developed to deal with these.
the sound card (or the outboard device of your choosing)
deals with these issues when passing audio data between analogue and
digital and analogue.

dale wrote:
Mark said
The device that presents the audio i.e the device with the D/A
converter must somehow be synchronized with the device that playsback
the data. If there is no synvhronization, and the playback spped is
not
the same as the presentation speed,

firewire is just the tranportation used by the computer to feed the
data hungry conversion process.
fire wire is not a device presenting audio
fire wire is a protocol for computers
developed by a company for use in handling audio/video data.


OK, so what ( to use your terms) happens if the firewire transports the
data faster than the hungry D/A needs it?

What happens if this continues for say an hour?

The D/A (presentation device) must store the extra data in a buffer.
If the buffer is not large enough, data will be lost. This is avoided
if there is a way to coordinate the average rates of the "playback" and
the "presentation".

If the D/A device does not have a very large buffer, the data comming
over the firewire interface must somehow be throttled.

Again, I agree, if the D/A is designed correctly, none of this causes
the type of jitter that effects the audio quality.

Mark

Mark wrote:


OK, so what ( to use your terms) happens if the firewire transports the
data faster than the hungry D/A needs it?


The D/A doesn't ask for data it isn't ready for. Firewire (or any other
communication channel for that matter) doesn't spray data like a
firehose, it only does what it's asked to do.

Think about this for a few minutes, then reflect on how this answers all
of your next statements.


What happens if this continues for say an hour?

The D/A (presentation device) must store the extra data in a buffer.
If the buffer is not large enough, data will be lost. This is avoided
if there is a way to coordinate the average rates of the "playback" and
the "presentation".

If the D/A device does not have a very large buffer, the data comming
over the firewire interface must somehow be throttled.

No, it just isn't requested. Buffers are implemented with a high-water
mark and a low-water mark: when the D/A empties the buffer below the
low-water mark (the buffer is NOT empty, it's just getting close), its
firmware will make a request for more data, a block large enough to
fill the buffer to a point between the high mark and the max buffer
size. If the buffer actually gets empty before that request is filled,
then you get a gap. It's really really easy to calculate what the
buffer size and high- and low-water marks need to be for any given level
of transport performance. And firewire's performance is very high, but
it doesn't work like Star Trek's computer that could send data faster
than the receiver could accept it (so it started smoking). That's just
stupid.


Again, I agree, if the D/A is designed correctly, none of this causes
the type of jitter that effects the audio quality.

And in D/A design, this is probably one of the most trivial issues.
You're right, these are design considerations, but all this stuff occurs
to all designers (I won't even qualify that with "hopefully") and is
dealt with appropriately. In other words, it's hard to understand why
you are pursuing this non-issue. Is there some problem with a piece of
equipment that you're trying to solve?

Hi all,

I've read the thread and I think there is a lot of misunderstanding here. I
am sorry, but what Bob says is completely wrong. There are basically two
modes of sending data through Firewi asynchronous and isochronous. The
first mode is for general data moving such as for moving data from a CPU to
a hard drive for example. This method is 100% reliable in terms of delivery
data, but does not guarantee timing. The second method was specifically
designed fo audio and video, where timing is generally more important than
loss of some data. You can compare it to UDP vs. TCP/IP, i.e. the data is
sent on time and no acknowledgment of the fact that it is received is
required, and thus if the receiver dropped the frame for any reason it is
not being resent since it doesn't make sense for streaming audio and video.

Now, as anything else Firewire can be used in different ways in actual
products, but most of the manufacturers are following what was proposed by
originally Yamaha in their mLAN spec and what later became the IEC61883-6
standard. This standard is built upon the idea of using the isochronous mode
and extracting the sampling clock with a PLL from the packet stream.
Unfortunately, there are lot of problems associated with this method and the
jitter is one of them. Please check out the following link for more info:
http://www.nanophon.com/audio/1394_sampling_jitter.pdf

This is not to say that there is no other way of doing it, but that's the
way which I believe is becoming common due to the fact that it is being put
in silicon by more than one IC manufacturer and due to the software support
of the 61883 spec in the latest OS's.

/Mikhail






"brubart" wrote in message
oups.com...
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

S O'Neill wrote:
Mark wrote:


OK, so what ( to use your terms) happens if the firewire transports
the
data faster than the hungry D/A needs it?


The D/A doesn't ask for data it isn't ready for. Firewire (or any
other
communication channel for that matter) doesn't spray data like a
firehose, it only does what it's asked to do.

Think about this for a few minutes, then reflect on how this answers
all
of your next statements.


What happens if this continues for say an hour?

The D/A (presentation device) must store the extra data in a
buffer.
If the buffer is not large enough, data will be lost. This is
avoided
if there is a way to coordinate the average rates of the "playback"
and
the "presentation".

If the D/A device does not have a very large buffer, the data
comming
over the firewire interface must somehow be throttled.

No, it just isn't requested. Buffers are implemented with a
high-water
mark and a low-water mark: when the D/A empties the buffer below the
low-water mark (the buffer is NOT empty, it's just getting close),
its
firmware will make a request for more data, a block large enough to
fill the buffer to a point between the high mark and the max buffer
size. If the buffer actually gets empty before that request is
filled,
then you get a gap. It's really really easy to calculate what the
buffer size and high- and low-water marks need to be for any given
level
of transport performance. And firewire's performance is very high,
but
it doesn't work like Star Trek's computer that could send data faster

than the receiver could accept it (so it started smoking). That's
just
stupid.


OK, then that's HOW they are coordinated. My point was simply that
such coordination is needed.


Again, I agree, if the D/A is designed correctly, none of this
causes
the type of jitter that effects the audio quality.

And in D/A design, this is probably one of the most trivial issues.
You're right, these are design considerations, but all this stuff
occurs
to all designers (I won't even qualify that with "hopefully") and
is
dealt with appropriately. In other words, it's hard to understand
why
you are pursuing this non-issue. Is there some problem with a piece
of
equipment that you're trying to solve?

I'm not pursuig any issue, just responding to the posts that said that
playback goes on its merry way with no regard for the D/A. My point is
some form of coordination between the playback and the D/A is required
so that the average rate of data playback = the average rate of data
consumption by the D/A.

You seem to agree with that.

Mark

Mark wrote:



I'm not pursuig any issue, just responding to the posts that said that
playback goes on its merry way with no regard for the D/A. My point is
some form of coordination between the playback and the D/A is required
so that the average rate of data playback = the average rate of data
consumption by the D/A.

You seem to agree with that.


Yep. Just ignore all those alarmists

MM wrote:

as anything else Firewire can be used in different ways in actual
products, but most of the manufacturers are following what was proposed by
originally Yamaha in their mLAN spec and what later became the IEC61883-6
standard. This standard is built upon the idea of using the isochronous mode
and extracting the sampling clock with a PLL from the packet stream.
Unfortunately, there are lot of problems associated with this method and the
jitter is one of them. Please check out the following link for more info:
http://www.nanophon.com/audio/1394_sampling_jitter.pdf

This is not to say that there is no other way of doing it, but that's the
way which I believe is becoming common due to the fact that it is being put
in silicon by more than one IC manufacturer and due to the software support
of the 61883 spec in the latest OS's.

At least one manufacturer has decided to engineer around the silicon http://rme-audio.com/english/techinfo/fwaudio_rme.htm

"Kurt Albershardt" wrote in message
...

At least one manufacturer has decided to engineer around the silicon
http://rme-audio.com/english/techinfo/fwaudio_rme.htm


I think MH Labs used a similar approach but much earlier...


/Mikhail

"Chel van Gennip" wrote in message
...

Firewire jitter: this problems occurs if there is a strong coupling
between the 8KHz timestamps and the clock recovery circuit, and different
clocks in the systems are on different ends of the specifications.

This is not correct. Consider a simple case of a computer sending firewire
stream to a D/A. If a 61883-6 or mLAN protocol is used, it will be an
isochronous packet stream. These standards assume that the sampling clock
will be extracted by a receiver from the stream. Extracting clock from a
packet stream is much more complex than extracting a clock from SPDIF or CD
and I doubt a low jitter solution actually exists today. If you try to
employ a buffer and an independent stable clock at the receiver end you will
eventually see either buffer under-run or over-run. The only cure is to
either use additional external clock, which a) defeats the purpose of 61883
and b) is impossible to connect to a computer; or not use 61883 or mLAN
protocols at all.

/Mikhail

In article writes:

Consider a simple case of a computer sending firewire
stream to a D/A. If a 61883-6 or mLAN protocol is used, it will be an
isochronous packet stream. These standards assume that the sampling clock
will be extracted by a receiver from the stream. Extracting clock from a
packet stream is much more complex than extracting a clock from SPDIF or CD
and I doubt a low jitter solution actually exists today.

Does the protocol actually include provisions for extracting a clock
signal from the data? That seems overly complicated. I'd think that
the data would just contain the information as to the sample rate and
that it would simply re-clock the samples on the receiving end. Since
most Firewire audio interfaces have a word clock input and/or output,
that could be used to synchronize word clocks within the system,
whether they were on other Firewire devices or something else.

I would think it would be reasonably easy to make adjustments to the
internal clock to keep the buffer safely out of the overrun or
underrun state. Modern crystal oscillators are pretty darn stable.
Even ten years ago, I could keep the audio of an ADAT and DAT in
reasonable sync for half an hour or more just free-running. And these
things keep getting better while they're getting cheaper.

But I don't design this stuff, so I don't really know.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

In article writes:

Conclusion: generating an accurate DA clock with less than 2.5ns jitter
and a jitter frequency of 1Hz, for isochonous firewire transfer, is easy
and cheap, so jitter in isochonous firewire should not be a problem.

Go for it. g



--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

It is also intersting to think, about the jitter caused by a band of
tape scraping across a playback head gap.

No one seems to think that is a problem even though it creates orders
of magnitude more "jitter" compared to most digital devices.

Ever actually look at what a 15 kHz tone looks like comming off a tape
playback on a scope?


Mark

"Mike Rivers" wrote in message
news:znr1108904064k@trad...

Does the protocol actually include provisions for extracting a clock
signal from the data? That seems overly complicated.

Yes, it does.

I'd think that
the data would just contain the information as to the sample rate and
that it would simply re-clock the samples on the receiving end.

The data does contain the information about the sample rate, but the
sampling clock is supposed to be extracted from the packet stream anyway.
The information about the sample rate can be used for optimizing PLL
settings or for something else...

I would think it would be reasonably easy to make adjustments to the
internal clock to keep the buffer safely out of the overrun or
underrun state.

I guess that's a possibility, although personally I don't like the idea of
slowly changing clock at the receiver side. I am not sure how inaudible it
is going to be. Besides, my point was that most of the devices on the market
are based on a handful of chips, which pretty much dictate the architecture
and as far as I know these chips follow either mLAN or 61883-6 model. There
are a lot of tricks one can do to solve the clock problem, but I believe any
of them would make devices non-compatible...

/Mikhail

"Chel van Gennip" wrote in message
...
On Sun, 20 Feb 2005 15:38:09 +0100, Mike Rivers wrote:

The receiver has, according to firewire specification, a 400MHz clock with
an error less than 100ppm, let's say actual frequency is 400,026,800 Hz.

There is actually no 400 MHz clock available to use. It exists only in the
wire link itself and inside of the PHY chip. The interface is actually
supposed to be driven from a 24.576 MHz crystal.

This way we get an adjustable DA clock of the right frequency and 2.5ns
jitter with a jitter frequency of 1Hz. Many studies, including
http://www.nanophon.com/audio/1394_sampling_jitter.pdf, show a jitter of
this size does not affect the audio signal.

2.5 ns seems an awful lot. Clock jitter can be thought of as a noise source
and there is a relationship that allows for expressing resulting converter
SNR from the clock jitter
(http://www.analog.com/UploadedFiles/...73066884897736
5163734AN501.pdf):

SNR= 20log(1/(2pi*F*Ta))
where F- frequency and Ta- ADC aperture uncertainty or jitter

For F=20kHz and Ta=2.5ns this gives the SNR of only 70 dB...

/Mikhail

In article . com writes:

It is also intersting to think, about the jitter caused by a band of
tape scraping across a playback head gap.

Scrape flutter is definitely a concern, but a good recorder, well
adjusted, doesn't have much. It's a design thing up front, but a
maintenance thing through the life of the tape deck. However, scrape
flutter had different artifacts than data clock jitter.

Ever actually look at what a 15 kHz tone looks like comming off a tape
playback on a scope?

Sure. It's nice and clean on a well adjusted tape deck with good
heads.

--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

In article znr1108950092k@trad, Mike Rivers wrote:
In article . com writes:

It is also intersting to think, about the jitter caused by a band of
tape scraping across a playback head gap.

Scrape flutter is definitely a concern, but a good recorder, well
adjusted, doesn't have much. It's a design thing up front, but a
maintenance thing through the life of the tape deck. However, scrape
flutter had different artifacts than data clock jitter.

And it has different artifacts because the spectrum is different.
Scrape flutter was actually a serious problem on the older machines
like the 350s, but by the time the last generation of tape machines
(ATR-100, A800) came out, it had pretty much been dealt with effectively.
There's still some on a modern machine, but the sidebands are far enough
away from the main tone and low enough that it's no longer the issue it
once was. Modern tape formulations also help a lot.

Ever actually look at what a 15 kHz tone looks like comming off a tape
playback on a scope?

Sure. It's nice and clean on a well adjusted tape deck with good
heads.

I remember aligning 350s with badly-worn heads and never been able to keep
a diagonal line on the 8 KC plyback tone for more than a couple seconds.
Today on the ATR-100 I can get a solid diagonal with a 24 KC record tone.

And you know, the clock stability on digital gear has changed just as much
in the past 25 years too.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

"Chel van Gennip" wrote in message
...
On Mon, 21 Feb 2005 06:12:19 +0100, MM wrote:


(http://www.analog.com/UploadedFiles/...73066884897736
5163734AN501.pdf):

Your link points to a 404 page.

Long links get wrapped sometimes. Please copy the whole link including the
part that was wrapped...

You forgot to mention that this formula asumes wide band clock jitter, for
a clock jitter of 2.5 ns and a fixed jitter frequency of 1Hz this
asumption is not valid.

I guess you are assuming your model where the clock frequency is gradually
changed based on the buffer gauge. I am assuming what the spec says, i.e. a
PLL extracting the clock directly from the packet stream and what actually
is being done in at least some of the chips on the market.

/Mikhail

"Chel van Gennip" wrote in message
...
On Mon, 21 Feb 2005 16:22:51 +0100, MM wrote:

Long links get wrapped sometimes. Please copy the whole link including
the part that was wrapped...

I did, it points to a 404 page.

I checked it again and it works for me. Try this: http://tinyurl.com/3qpnm
If it fails too then just go to www.analog.com and search for the appnote
AN-501.

/Mikhail