R/E/P Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 2 [3] 4   Go Down

Author Topic: Jitter Specification Input Requested  (Read 15341 times)

Nika Aldrich

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 832
Re: Jitter Specification Input Requested
« Reply #30 on: May 03, 2004, 02:04:23 PM »

sfdennis wrote on Mon, 03 May 2004 18:22

Nika,
Well, you?ve identified my major concern with the suggestion. The way I thought about it is was you would take the jitter spectrum as you suggested early in the thread, and feed it into a program that would spit out the THD+N graph. By using a program as a ?virtual converter?, you?ll be able to get around the idiosyncrasies of any real converter that might be used in a given test. After all, real converters have their own flaws and you wouldn?t want a clock?s jitter spec to be influenced by a particular choice of converter.


OK.  We're in agreement there.

Quote:

As usual, the devil is in the details.


OK.  We're in agreement there, too.  Smile

Quote:

First you?d have to take the output of a real jitter spectrum measurement such as is available from the AP setup. That?s the easy part. Then a program would have to model the spectrum as a linear combination of noise and jitter frequency components.


Well really there is no noise component (I mentioned phase noise earlier, but that is so not the problem and so far below the noisefloor of discussion that we should drop the noise spec).  As for reproducing the THD spec as a biproduct of noise that is good, but it will change dependent upon sample frequency.

Quote:

Steve?s committee will have to agree on basis functions for modeling jitter.


It doesn't need to be modeled, really.  It's a pretty straight ahead formula.  

The two issues that we run into are the range of the jitter spectrum we are going to require in the spec, and the deviance that any downline box can have on the results.  Again, much of the problem is the PLL, not the clock!

Nika.
Logged
"Digital Audio Explained" now available on sale.

Click above for sample chapter, table of contents, and more.

Ethan Winer

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 571
Re: Jitter Specification Input Requested
« Reply #31 on: May 03, 2004, 02:50:16 PM »

Stefan,

> why would anybody say that jitter is irrelevant? That's akin to a reel to reel manufacturer saying that tape flutter is irrelevant <

That's a great analogy, and I agree with it. The main difference between analog tape flutter and digital jitter is that one is typically present in amounts large enough to notice, and the other is not. You can easily hear 1 percent of flutter. You cannot hear 0.0001% flutter at all.

Hiss is a problem if it's not far enough below the signal, but it's not a problem if it's very soft. Same for distortion, hum, and every other audio artifact. It's all a matter of degree. If something is 80-90 dB or more below the music, it's not a terrible problem. And if it's below the noise floor of the medium, then it's not a problem at all.

--Ethan

Ethan Winer

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 571
Re: Jitter Specification Input Requested
« Reply #32 on: May 03, 2004, 02:54:06 PM »

Dennis,

> Using such a graph, it would be fairly easy to settle Ethan and Nika’s argument. <

Yes, which is why it amazes me that people are still arguing about this. So somebody please give me a worst case number expressed in dB below the program. Then apply Fletcher-Munson to make sure 3 KHz gets the weight it deserves, while minimizing the contribution of low frequencies.

--Ethan

Nika Aldrich

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 832
Re: Jitter Specification Input Requested
« Reply #33 on: May 03, 2004, 03:47:40 PM »

Ethan Winer wrote on Mon, 03 May 2004 19:54

Dennis,

> Using such a graph, it would be fairly easy to settle Ethan and Nika?s argument. <

Yes, which is why it amazes me that people are still arguing about this. So somebody please give me a worst case number expressed in dB below the program. Then apply Fletcher-Munson to make sure 3 KHz gets the weight it deserves, while minimizing the contribution of low frequencies.

--Ethan


...and then put it in a real world room where nodes and nulls can expose things that otherwise would be burried below the thresholds of audibility...

Nika.
Logged
"Digital Audio Explained" now available on sale.

Click above for sample chapter, table of contents, and more.

sfdennis

  • Newbie
  • *
  • Offline Offline
  • Posts: 34
Re: Jitter Specification Input Requested
« Reply #34 on: May 03, 2004, 03:51:42 PM »

Quote:

Well really there is no noise component (I mentioned phase noise earlier, but that is so not the problem and so far below the noisefloor of discussion that we should drop the noise spec).


Well, jitter has noise in that you can’t tell in advance what the time-error will be at a given instant—it is random. Is it white noise? Well, as I understand it, close-in phase noise falls off at 1/f making it more pink than white. But the fact that it is random—read not deterministic—makes it noise. And so you have to model it as a random variable. While such noise may be so low as to be uninteresting, why throw it out? If it is not interesting, then it won’t show up in the graph.

In general, the test should be as comprehensive as possible; noise should be part of the spec. Otherwise manufacturers might claim that their device is ‘better’ because it is quieter and they won’t have to defend (1) that their device is indeed quieter and (2) that it matters. In that event, we'd be back to where we started.

Quote:

It doesn't need to be modeled, really. It's a pretty straight ahead formula.


The resulting amplitude error from a given timing error is a pretty straightforward formula, but the actual sampling time error produced by the device is not so easy. If the jitter spectrum does not have a trivial (flat) shape, then a function that produces a timing error is not trivial at all. As I mentioned, the jitter function will be some combination of perhaps many noise and periodic components.

Quote:

The two issues that we run into are the range of the jitter spectrum we are going to require in the spec, and the deviance that any downline box can have on the results. Again, much of the problem is the PLL, not the clock!


While I haven’t thought much about the range of the jitter spectrum, I do think that the clock interfaces of downstream devices should be considered separately. Clock manufacturers have no control over what folks might be downstream of their devices.

A clock receiver should not only specify the jitter of its internal clock, but also its ability to reject incoming jitter—that’s what a PLL is supposed to do. All PLLs do to a greater or lesser extent, and that should be spec’d. I can offer no insights into how to make PLL specs more user-friendly.

-Dennis
Logged
Dennis Tabuena

Nika Aldrich

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 832
Re: Jitter Specification Input Requested
« Reply #35 on: May 03, 2004, 04:21:50 PM »

sfdennis wrote on Mon, 03 May 2004 20:51

Well, jitter has noise in that you can?t tell in advance what the time-error will be at a given instant


Not exactly.  For the sake of this conversation there are two types of jitter - phase noise and everything else.  Phase noise is virtually irrelevant in clocks.  It's the everything else - the electronic circuitry, filtering, power supply, etc. that serves to provide the jitter that is consequential for the audio industry.  Even more than that, however, the internal PLLs are pretty crucial.  Everything else IS deterministic, periodic, and therefore causes distortion.  

In general, the test should be as comprehensive as possible; noise should be part of the spec. Otherwise manufacturers might claim that their device is ?better? because it is quieter and they won?t have to defend (1) that their device is indeed quieter and (2) that it matters.

That's OK.  It doesn't actually matter.  Phase noise is so far below anything that can be audibly discernable that it truly doesn't matter as far as I can tell.

The resulting amplitude error from a given timing error is a pretty straightforward formula, but the actual sampling time error produced by the device is not so easy. If the jitter spectrum does not have a trivial (flat) shape, then a function that produces a timing error is not trivial at all. As I mentioned, the jitter function will be some combination of perhaps many noise and periodic components.

Look at the jitter spectrum of any device in our industry and you'll find that the shape of the jitter spectrum is very static.

A clock receiver should not only specify the jitter of its internal clock, but also its ability to reject incoming jitter?that?s what a PLL is supposed to do. All PLLs do to a greater or lesser extent, and that should be spec?d. I can offer no insights into how to make PLL specs more user-friendly.

But really, perhaps we should just start paying more attention to the PLLs than the clocks.  It's the PLLs that really make the difference.

Nika.
Logged
"Digital Audio Explained" now available on sale.

Click above for sample chapter, table of contents, and more.

sfdennis

  • Newbie
  • *
  • Offline Offline
  • Posts: 34
Re: Jitter Specification Input Requested
« Reply #36 on: May 03, 2004, 08:37:44 PM »

Nika Aldrich wrote on Mon, 03 May 2004 13:21


Look at the jitter spectrum of any device in our industry and you'll find that the shape of the jitter spectrum is very static.



Not sure, Nika, I know what you mean by ‘very static’. I should say that I haven’t seen many jitter spectra, but the very best among the devices I’ve seen have a fairly dense 1/f (6-20db/decade) rolloff away from their clock frequency. That would represent the random noise. By ‘dense’ I mean that there is a lot of color under the curve. Many jitter spectra have one and sometimes two spurs in the tails. These would represent the periodic jitter components. None of the real jitter spectra I have seen consist of a few simple lines. Is this what you mean by ‘very static’?

Quote:


But really, perhaps we should just start paying more attention to the PLLs than the clocks.  It's the PLLs that really make the difference.



Sure, got any ideas?

-Dennis

ps. Why are my single quotes showing up as question marks when you quote me? It makes me thing that you question everything I say? Very Happy -D
Logged
Dennis Tabuena

Zoesch

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 269
Re: Jitter Specification Input Requested
« Reply #37 on: May 03, 2004, 09:24:19 PM »

Dennis... your quotes are changing because you are probably typing your responses in word or some other word processor and when you copy them they are copied as Unicode...

Anyway, your appreciation of jitter is correct, the reality is that jitter is random within a specific frequency band (Or else clocks would be useless), it's the width of that frequency band and the periodicity that concerns us. Jitter in itself can only be measured as how many errored pulses there are within a specific time period, but if you were to compare two different samples of the clock signal spanning the same lenght in time, you'll realize that the errors don't happen exactly at the same pulses.

That's why measuring jitter in ppm to me is useless, were the manufacturers to provide the spectral component of that jitter and it would make a lot more sense.
Logged
It has always been Ringo's fault

Nika Aldrich

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 832
Re: Jitter Specification Input Requested
« Reply #38 on: May 04, 2004, 10:29:10 AM »

Dennis Tabuena wrote on Tue, 04 May 2004 01:37

Not sure, Nika, I know what you mean by ?very static?. I should say that I haven?t seen many jitter spectra, but the very best among the devices I?ve seen have a fairly dense 1/f (6-20db/decade) rolloff away from their clock frequency. That would represent the random noise. By ?dense? I mean that there is a lot of color under the curve. Many jitter spectra have one and sometimes two spurs in the tails. These would represent the periodic jitter components. None of the real jitter spectra I have seen consist of a few simple lines. Is this what you mean by ?very static??


Dennis,

Are you looking at the crystal itself, or at the output of the box, on the BNC connector?

Also, dense jitter spectra that has a steep roll-off/octave will not manifest itself as noise on a signal.  It will manifest itself as distortion.  Feed a 1KHz signal through a converter with this signal and listen/look at the results.  Then do a 5KHz signal.  It would very clearly not manifest itself as noise.  Whereas a clock signal itself MAY be noisy, the way it manifests itself may not be.

Nika.
Logged
"Digital Audio Explained" now available on sale.

Click above for sample chapter, table of contents, and more.

Nika Aldrich

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 832
Re: Jitter Specification Input Requested
« Reply #39 on: May 04, 2004, 10:42:51 AM »

Zoesch wrote on Tue, 04 May 2004 02:24

Anyway, your appreciation of jitter is correct, the reality is that jitter is random within a specific frequency band (Or else clocks would be useless), it's the width of that frequency band and the periodicity that concerns us. Jitter in itself can only be measured as how many errored pulses there are within a specific time period, but if you were to compare two different samples of the clock signal spanning the same lenght in time, you'll realize that the errors don't happen exactly at the same pulses.


Zoesch,

This is absolutely erroneous or I completely misunderstand what you are saying?  We measure jitter by plotting the variations and amplitude of the clock irregularities.  If you measure the variation between every clock pulse and absolute time and plot it on a graph you will see predictable behavior in the clock's variation from accuracy.  We don't measure how many "errored pulses" there are over time.  Every pulse is erroneous, so we measure the amplitude of the error.  A 1KHz jitter signal will manifest itself as timing variations that cycle 1000 times per second, so on a 8KHz clock we'll see a complete cycle of error in 8 samples.  If A is the amplitude of the jitter then the formula for the errors might be as follows:

Pulse 1 - On time
Pulse 2 - early by A(pi/4)
Pulse 3 - early by A
Pulse 4 - early by A(pi/4)
Pulse 5 - On time
Pulse 6 - late by A(pi/4)
Pulse 7 - late by A
Pulse 8 - late by A(pi/4)
Pulse 9 - repeat.

In order to determine the frequency content of the jitter you do an FFT of the plot of the errors over time.  The FFT of the jitter (the jitter spectrum) will tell you the amplitude and frequencies of the sideband distortion created by the jitter in the sampling process.  The specific amount is also affected by the frequencies and amplitude of the frequencies being sampled, all very similar to wow and flutter.

Nika.
Logged
"Digital Audio Explained" now available on sale.

Click above for sample chapter, table of contents, and more.

Bob Olhsson

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 3968
Re: Jitter Specification Input Requested
« Reply #40 on: May 04, 2004, 12:24:53 PM »

Zoesch wrote on Mon, 03 May 2004 20:24

 
That's why measuring jitter in ppm to me is useless, were the manufacturers to provide the spectral component of that jitter and it would make a lot more sense.

Manufacturers just love to advertise meaningless specs. A spectral analysis of FM distortion is the only meaningful way to describe it.

The other problem with wow and flutter (consumer electronics industry hacks changed the names so they could make digital gear look better on paper) is that when you chain a series of devices, you get additional sum and difference sidebands.

Thankfully jitter in digital video looks like very obvious crap on the screen so chip-makers and manufacturers are finally being held to account and are no longer able to hide their crappy engineering behind claims of a need for double-blind testing.

sfdennis

  • Newbie
  • *
  • Offline Offline
  • Posts: 34
Re: Jitter Specification Input Requested
« Reply #41 on: May 04, 2004, 12:38:29 PM »

Nika Aldrich wrote on Tue, 04 May 2004 07:29

Are you looking at the crystal itself, or at the output of the box, on the BNC connector?

Looking at the output of the box using a very nice spectrum analyzer and occasionally a DSO scope. In all cases with a measurement-grade bnc connector. But, FYI: Can't look at the crystal itself w/o the supporting oscillator circuitry.

Quote:

 
Also, dense jitter spectra that has a steep roll-off/octave will not manifest itself as noise on a signal.  It will manifest itself as distortion.  



Sure if it is far enough away from the clock frequency and rises well above the absolute noise floor. The only things I've seen like that are the spurs I mentioned earlier.

Quote:


Feed a 1KHz signal through a converter with this signal and listen/look at the results.  Then do a 5KHz signal.  It would very clearly not manifest itself as noise.  Whereas a clock signal itself MAY be noisy, the way it manifests itself may not be.


Again it depends on where the peak is, how high it rises and how fast. But that's what this whole thing is about. Take a jitter spectrum and produce a THD+N graph from it.

-Dennis
Logged
Dennis Tabuena

sdevino

  • Full Member
  • ***
  • Offline Offline
  • Posts: 153
Re: Jitter Specification Input Requested
« Reply #42 on: May 04, 2004, 12:55:52 PM »

I think we ought to jump up and take a little broader view.

The only noise or jitter that will matter in the end is what ever it is that makes it to the actual input of the ADC or DAC circuit in the actual IC chip. So we need to understand how to determine this given a real world circuit.

It turns out this is pretty hard to do, very expensive and almost never really done. For one thing its hard to measure the jjitter at the iput to the converter because you need to get inside the chip itself with a probe. For another thing attaching a probe to the clock circuit changes the clock cicuit and therefore introduces errors contributed by the measurement process.

So from a practical standpoint you are left with measurements that can be used to correlate one error to another. For instance there is a direct correlation between jitter and noise, whether measured as a noise floor or in PPM. So one means of measure would be to measure other noise sources which are relatively easy, then derive the jitter as an additive element.

Sweeping the input is a questionable approach as well since you are using  a very non-typical input signal to determine typical response. Applying a broadband signal or carefully designed noise source and subtracting its spectrum from the measured result would provide much more real world data (in less time as well).

The topic is Audio Engineering though. We need to get back to what effect jitter has on the audio spectrum and how would measuring jitter provide usefull input to a Recording Engineer. There a lots of EE's out there analyzing this topic from  design standpoint.

So far I like the full jitter+noise approach. It seems to offer the most usefull insight to what would bother me as an audio engineer. Just as THD+Noise has become a pretty standard performance gauge..

Logged
Steve Devino

Granite Rocks Recording Studios
Studio gear design and setup

Ethan Winer

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 571
Re: Jitter Specification Input Requested
« Reply #43 on: May 04, 2004, 02:57:50 PM »

Nika,

> and then put it in a real world room where nodes and nulls can expose things that otherwise would be burried <

Of course one could make that point for simple harmonic distortion and even hiss. But first let's start with a number that reflects the inherent audibility of jitter alone. Adding that extra complication just obfuscates the issue, and doesn't address the only important question: How many dB below the music is jitter typically?

--Ethan

Zoesch

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 269
Re: Jitter Specification Input Requested
« Reply #44 on: May 04, 2004, 08:46:58 PM »

Nika,

That should've read Clock Stability (not jitter) can only be measured as a function of errored pulses... anyway... even my lowly Tektronix analyzer can give you the jitter power density down to central frequency, width, amplitude, etc. Better scopes can give you statistical distribution of jitter including, mean, average, standard deviation and higher order moments and some can even give you time/amplitude measurements... so it's not as if the tools to measure jitter don't exist, manufacturers choose not to use them.

As to how to report these results... why are we reinventing the wheel? ITU-T and ANSI have very descriptive standards for clocking, wander & jitter performance and synchronization. Failing that, the spectral power density of jitter should be sufficient for 99% of people.
Logged
It has always been Ringo's fault
Pages: 1 2 [3] 4   Go Up
 

Site Hosted By Ashdown Technologies, Inc.

Page created in 0.059 seconds with 20 queries.