FireWire jitter

Archived from groups: rec.audio.pro (More info?)

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

Archived from groups: rec.audio.pro (More info?)

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" <bbartlett@crownintl.com> 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

Archived from groups: rec.audio.pro (More info?)

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

Archived from groups: rec.audio.pro (More info?)

"Mark" <makolber@yahoo.com> wrote in message
news:1108685078.631363.303380@z14g2000cwz.googlegroups.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

Archived from groups: rec.audio.pro (More info?)

In article <1108685078.631363.303380@z14g2000cwz.googlegroups.com> makolber@yahoo.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 (mrivers@d-and-d.com)
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 here: double-m-eleven-double-zero at yahoo

Archived from groups: rec.audio.pro (More info?)

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.

Archived from groups: rec.audio.pro (More info?)

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?

Archived from groups: rec.audio.pro (More info?)

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

Archived from groups: rec.audio.pro (More info?)

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>

Archived from groups: rec.audio.pro (More info?)

On Fri, 18 Feb 2005 22:55:55 +0100, MM wrote:

> 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

If I may summarize the paper: theoretically there are problems, problems
that can be solved.

Like most jitter "problems", e.g. SPDIF cable jitter CD reader jitter it
is possible in theory to create circumstances where this jitter is a
problem. In a good implementation you don't find these theoretical
problems.

CD jitter problems: the bitstream of the CD is buffered and a cheap and
stable clock is used to clock the bitstream.

SPDIF cable jitter: this problem is only existent if the cable is driving
a DA converter directly and you use a 75ohm coax that attentuates
6db/octave at 1 MHz, most 75Ohm coax does not even has these problems at
1GHz.

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.

If you want to measure jitter: measure the jitter at the DA converter
clock in a real life situation or measure problems on the generated analog
signal. The rest is only interesting for theoretical studies of for
selling mega$ cables etc. E.g. $2000 for a 75Ohm coax with RCA connectors.
http://www.fatwyre.com/digital1_05.html

If you are in a recording environment, and you only have conversion from
analog so digital, and digital transfer to storage or processing, there is
no way at all you could encounter jitter problems.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com

Archived from groups: rec.audio.pro (More info?)

On Sun, 20 Feb 2005 00:55:03 +0100, MM wrote:

> "Chel van Gennip" <chel@vangennip.nl> wrote in message
> news:37phudF5fgjl3U1@individual.net...
>>
>> 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.

Two clocks on a system can be off by a maximum of 200ppm. This means that
a buffer of only 1000 samples (or 0.01 sec) will do to buffer about 50
seconds the maximal difference between clocks for a 96KHz sample rate. So
a simple slow clock adjustment for the DA clock and moderate buffering
will solve the potential problem. Clock adjustment can be done easely by
monitoring buffer fill at the receiver side. The paper allready stated
that clock adjustments at a rate of one (~1 ppm) adjustment per second
will not have any effect on the output analog signal. Monitoring the
buffer fill and adjusting the DA clock rate with about 1ppm per second is
not too difficult for hardware that can handle firewire protocol. So my
statement is that clock recovery from the packet stream is not at all
difficult. The paper gives a theoretical explanation. Therefore my
suggestion to measure actual (high frequency) clock jitter at the DA
converter in a real system.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com

Archived from groups: rec.audio.pro (More info?)

On Sun, 20 Feb 2005 15:38:09 +0100, Mike Rivers wrote:

> 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.

It seems indeed quite easy:

Design of a DA clock for a firewire isochronous transfer, copyright 2005
Chel van Gennip ;-)

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.
The 96KHz datastream has a samplerate of 96KHz with an error less than
100ppm, let's say the actual samplerate of the data source is 95995.39Hz.

If we want to derive the DA clock from our 400MHz firewire clock we should
use a divisor of 4167.1459. We create the divisor by using a divisor of
4167 for 85410 times followed by a divisor of 4168 for 14590 times.

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.

The needed divisors can be calculated and adjusted by simple aritmetic
from input timestamps and actual output performance. As a start a divisor
of 4166.667 can be used and adjusted to meet actual requirements

We are using: the available 400MHz 100ppm firewire clock, available logic
for processing the protocol, one hardware counter that is adjusted by
software twice a second.

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.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com

Archived from groups: rec.audio.pro (More info?)

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

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> 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

Archived from groups: rec.audio.pro (More info?)

On Mon, 21 Feb 2005 06:12:19 +0100, MM wrote:

> 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/Application_Notes/395652273066884897736
> 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...

Your link points to a 404 page.

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. You can easely understand this by lowering the
jitter frequency to 1 change per day. The formula still gives a 70dB noise
figure, caused by an incident that will take another 24 hours to happen.
You demonstrated exactly the misuse of a theoretic approach based on wrong
assumptions. Scientific papers are not ment to pick some formulas and use
them out of context.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com

Archived from groups: rec.audio.pro (More info?)

In article <znr1108950092k@trad>, Mike Rivers <mrivers@d-and-d.com> wrote:
>In article <1108941032.054815.87690@o13g2000cwo.googlegroups.com> makolber@yahoo.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."

Archived from groups: rec.audio.pro (More info?)

On Mon, 21 Feb 2005 16:22:51 +0100, MM wrote:

> "Chel van Gennip" <chel@vangennip.nl> wrote in message
> news:37ttd8F5ggb6nU1@individual.net...
>> On Mon, 21 Feb 2005 06:12:19 +0100, MM wrote:
>>
>>
> (http://www.analog.com/UploadedFiles/Application_Notes/395652273066884897736
>> > 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...

I did, it points to a 404 page.

>> 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.

From the paper you supplied:

IEC 61883-1 defines a method of transmission of real-time digital
audio/video data over IEEE1394. In particular it defines a common
isochronous packet (CIP) format that standardises support for real time
audio and video streams. The CIP format provides for a time stamp (SYT)
based on the lower 16 bits of the IEEE1394 CYCLE_TIME register of the
transmitter. The SYT may be used to determine the presentation time of
the signal at the receiver. The SYT has the same resolution as the
CYCLE_TIME register of 1/24.576ms, or 40ns.

So your assumption the spec specifies a PLL implementation is wrong. The
method I described just implemented this description.

You were responding to my post with an exact description of the method, so
no assumptions about the method I described were needed. A clear situation
with a clock, adjusted twice a second resulting in a maximum jitter of
2.5ns with a fixed jitter frequency of 1Hz. In fact, the method is an
implementation of extracting the AD clock from the packet stream. You
responded:

> 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/Application_Notes/395652273066884897736
> 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...

So again:
This will not result in noise or other artifacts. You demonstrated exactly
the misuse of a theoretic approach based on wrong assumptions. Scientific
papers are not ment to pick some formulas and use them out of context. BTW
the paper you earlier supplied says about jitter problems:

Masking theory suggests that the maximum amount of jitter that will
not produce an audible effect is dependent on the jitter spectrum. At
low frequencies this level is greater than 100ns, with a sharp cut-off
above 100Hz to a lower limit of approximately 1ns (peak) at 500Hz
falling above this frequency at 6dB per octave to approximately 10ps
(peak) at 24 kHz for systems where the audio signal is 120dB above the
threshold of hearing.

In the view of the more recent research cited above this may be
considered to be over cautious. However the indication that jitter
below 100Hz is more than 40dB less audible than jitter above 500Hz is
useful when determining the properties of jitter attenuation devices.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com