Jump to content
IGNORED

Some additional thoughts about measuring jitter


Recommended Posts

As an addition to my post

 

http://www.computeraudiophile.com/node/1640

 

I open a new thread with just two very short additions

 

But it would be good to read the above mentioned post, so that the content mustn’t be repeated here.

 

Point 1: Jitter Theory

 

A lot of people are talking about jitter in different posts, but I really feel that it would be good, if some of them would get some more information in order to understand better this field of digital audio. I highly recommend nearly everything Julian Dunn has written about Jitter. He invented the so called J-Test (Jittertest), a fantastic signal, back when he was with prism sound. Then he was with nonaphone and continued his research, so you can find some articles from this period in the web and finally joined Audio Precision and put his technique into their measurement system and with this system you can do a lot of jitter measurements, as I have also done.

 

In this time he wrote a fantastic book “Measurement Techniques for Digital Audio” (Audio Precision Application Note #5). This is really all you have to know about Jitter in DA, in AD and in DD process. Very fine reading, starts from the beginning and getting deeper into details. I like this book, the J-Test, and the audio precision system a lot. So head out at least for the book.

 

Point 2: Jitter values

 

Some years ago I “only” looked at the broadband value of the jitter, given between say 200 ps and 4 ns or similar. And even if you are measuring “only” the broadband jitter, you can choose between peak values or RMS values and chose between frame jitter or bit cell jitter (just a very short explanation). I those days than I recognized that some units with for example 400 ps sounds much more cleaner than units with only 200 ps jitter, or that some units with 200 ps jitter sounded very harsh while others with 400 ps sounded very smooth.

 

So this was the time that I analyzed the jitter over the audio band (all well described by Julian Dunn, this is nothing I have invented). With this method I have a much more better look in the kind of jitter, whether it is signal correlated or more random, more of low frequency modulated of more higher audio frequency jitter. So nowadays, I am no longer interested in the broadband value of the jitter, but only at the FFT of the jitter signal.

 

This is similar to the THD therm. The number alone, doesn’t say you anything about the sound, but if you do a FFT analysis, then you have a chance to understand the sound. I do not want to say, that if I am looking on the FFT I can say how it will sound, but it gives me a good understanding to bring this in relation to the sound and a good starting point, what to do to improve the sound.

 

Juergen

 

 

Link to comment

Your findings are dead-on IMO. It's really the frequency content, and furthermore how this is related to the signal that matters than the absolute magnitude. The magnitude tells you very little about the audibility of jitter when you get down to reasonably low levels. For instance I use two clocks that are both rated at 2psec RMS jitter, but they dont say anything about the spectra in the specs. The two clocks sound noticably different in my system.

 

A useful jitter characterization standard should be created for audio. The current measurements tell you nothing.

 

Steve N.

Empirical Audio

 

Link to comment

From Dr Chris Smith Roke Manor (Divison of Siemens)

 

Ash,

 

Reading through that CA thread on jitter, it occurred to me that no one had bothered to check out the science.

So here it is. The effect of jitter on a sampled signal may be expressed as a signal to noise ratio :-

 

SNR(jitter) = -20*log(2*pi*tor*freq) dB

 

Where

tor = the jitter in seconds.

freq = frequency of the sinewave test signal in Hz.

 

So the degradation is proportional to frequency, and the worst case would therefore be freq=20kHz. However, as the ear's sensitivity has rolled off by at least 20dB at 20kHz, a more realistic test would be ~4kHz.

 

If we set the SNR target due to jitter at 100dB at 4kHz, so as to be masked by the 16 bit quantisation noise, plugging the numbers into the equation above gives us the absolute minimum audible jitter = 400ps. This is way above the level deemed to be necessary by the armchair experts. Maybe you could run it past Martin.

 

Chris.

 

DAC Chip manufacturers quote jitter figures and effectively dictate how you build a DAC. All modern A to Ds and D to As (the only places jitter occurs) are well with in this specification and can be further improved with SRC if necessary.

 

Jitter is yesterday's news IMO and not really an issue.

 

Ash

 

Link to comment

Hi Juergen, allow me to chime in.

 

Although I am much more at the beginning of the measuring process, people may know I am in the very same boat, and btw have read parts of Julian's writings as well (and have it at hand as a guide).

 

Personally I do not know what it is we hear for changes, and while it is obviously the most logical it would be about changes on jitter or the jitter spectra indeed, I wonder whether this really is so. But do we have another explanation ? I'm afraid we have not.

 

One explanation could be that the way we measure jitter is not right, and all tests applying it, flaw. Could that be ? hmm ...

 

I am ignorant enough to look for reasons where I possibly should not because of a lack of knowledge, but let me begin with one question I have, and with possible interesting answers :

 

I must excuse myself to those who read it for the 100th time, but I am very much dedicated to "non oversampling" which means nothing less than what goes digitally in for whatever waveform, must come out like that on the analogue side. This, opposed to oversampling DACs (think delta-sigma here) which explicitly do not. The story about a pure square turning into a pure sine ...

Now if someone could tell me :

 

When you imagine the most precise digital wave of random type going into the DAC, some wave coming out of it, but due to heavy oversampling it is impossible to have stayed the same (take that square and you will understand), how in the world would a measuring device be able to measure jitter by means of comparing the digital input to the analogue output ? Still these devices do ...

 

Going a step further on this ...

Knowing what it takes to ever pertain the digital wave, and then looking at the DAC chips needed for it, including the NOS principle and some filtering, or no filtering if you want ... and now compare this to the A/D chips and used principle on the input side of the measuring device and *knowing* that no chips exist other than sigma-delta to do it, hence oversampling and a different kind of filtering applied to sort it all out ... how in the world jitter measurement with reliable results can come from this ?

 

I say it can't. Not without further understanding.

But, assuming that there isn't anything to understand, I'd dare claim that something must be wrong, because jitter can still measure as a few ps, while the signal has deformed to a high extend and there is no way this is off a few ps only.

 

I know, I'm talking apples and oranges here, because jitter should not be compared with a resulting signal as such, but when I'd be talking apples and apples things don't fit, and there won't be such a thing as jitter measurement at the analogue output.

But measurement still suggests it ... (including Julian Dunn btw).

 

The only real conclusion I can have about this - in this stage of knowledge - is that the presented jitter figures can't be right. From this must follow that with the right figures at hand (but who has them, and who can measure them) we might see something completely different. The results might be in the hundreds of ns, and who knows the one software may show 100ns less opposed to the other.

 

Then, my earlier suggestion about what we're perceiving is not jitter but "something else" is indeed my thinking, although it would always be a derival of jitter. I mean, suppose jitter is a phenomenon which allows multiplication further down the line (like amplification does), the intrinsic jitter of a DAC might be a few ps, but right after that the error is amplified (I/V stage) and possibly is then very ready to be perceived.

Again this is the same apples and oranges, but assuming that jitter just cannot be measured once being in the analogue domain, what's left is at the incoming side of the DAC chip and any variation (jitter) there will be amplified right after that. Btw to my imagination this "ampllified" is always to be seen as resonance, or IOW repeating patterns, for the exact same reason dither was invented.

 

Lastly for now :

If it indeed would be so that jitter is to be measured at the analogue Out of the DAC (vs. the digital In), it is my suggestion to capture the analogue stream and compare it with the digital. Take a normal music file !

I don't think it is necessary to tell that hardly anything comparable will come from it, and even after careful level adjustment (the amplitudes of the output have to be calibrated with the amplitudes of the input) you won't get anywhere. Use a delta-sigma DAC and you won't even find compareable points, but with an NOS you'll still be shocked. But of course, nobody is even thinking of starting up a test like this (but I did) because we all know what comes from it : mess. This mess for sure starts at the delta-sigma capturing, but also will emerge at the (in-chip if so) I/V stage.

 

And still our expensive measurement devices are able to come up with figures at the ps level ?

How ??

 

Peter

(now tell me how many mistakes *I* made hehehe -> just trying to understand !)

 

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Ashihara did an experiment indicating that random jitter is not audible below the 250 ns: http://www.jstage.jst.go.jp/article/ast/26/1/50/_pdf

According to Ivar Løkken: We can see that the audibility threshold decreases from 500ns at low frequencies to as little as 20ps at 20kHz. Especially when using formats or converters with high sample-rate this will be a major issue.

http://www.iet.ntnu.no/courses/fe8114/files/Report_audiodac.pdf

 

 

 

 

 

Link to comment

Roseval, thanks. And somehow so logical.

 

My problem is : I am quite confident that general jitter has more impact on the LOWER frequencies.

I am breaking my brains on the why, but all is in that direction.

 

This is similar to my observation that highres material (up to 24/192) discerns in the bass area (for the better). And I can't think of why (logic tells me, like Ivar Løkken's telling, that it should be the higher frequencies).

 

Peter

 

PS: Does anyone have a clue why I was contacted today by a dutch Audio Precision salesrep ? coincidences exist of course, but an out of the blue "let me help you with the right analyser for your problem" ... neah ...

:-)

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

"If it indeed would be so that jitter is to be measured at the analogue Out of the DAC (vs. the digital In), it is my suggestion to capture the analogue stream and compare it with the digital."

 

This is actually being done now, more and more. This is what John Atkinson does. Usually, a single frequency is put to the DAC and then the overtones and jitter contribution is measured with a RF spectrum analyzer. This is useful, but still no correlation to audibility.

 

Steve N.

 

Link to comment

Does anyone have a clue why I was contacted today by a dutch Audio Precision salesrep ? coincidences exist of course, but an out of the blue "let me help you with the right analyser for your problem" ... neah ...

 

But in the end maybe not so OT at all. What happened ?

 

The email I got from the salesrep was responded by me with the question how the man got hold of my name. After a few emails back and forth he could prove that I asked information about AP products on the AP website. I had a confirmation email of it ... hmm ...

 

Looking at the website, I did not recognize it at all, and besides that, this was from last January 18. I would have known *and* I just have an audio analyzer. So why ?

 

Then it sprung to my mind that the "book" from Julian Dunn only came with some kind of registration first. So it is this what I must have done on January 18. Haha, I was not making things up about reading mr. Dunn.

 

Well, by indeed pure coincidence the salesrep contacted me today, never knowing that I registered only because of getting that book. So yes, coincidences exist.

 

In the mean time I kind of told the man that J.D. hopping from Prism to Audio Precision, did not help AP much, because users don't get it. Yes, I fed him with Prism users (me) don't get it either. And thus my next question to the kind man (apparently still working after 11pm which was the time overhere 40 minutes ago) : .... "but might you be willing to let Julian Dunn contact me ... yes please !".

 

Now let's see what will come from that.

Maybe nothing, but if so I will let it know of course.

 

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

"Ashihara did an experiment indicating that random jitter is not audible below the 250 ns"

 

This would be interesting, except that random jitter is not the problem IMO, it's correlated jitter that is more audible. It's a brain thing, not an ear thing.

 

Steve N.

 

Link to comment

Ok, now I feel stupid.

 

On some kind of "positive side" this may explain why AES17 still is as it is. It wouldn't be so that he was the only one capable of doing such things ? But if so, something is quite some years behind now and can't catch up ?

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

I just want to add one point into this discussion to help, that we speak the same “language”.

 

I am well aware of the math about jitter etc, but we have to state clear about what numbers we are talking about. This can be either RMS or Peak-Peak value (depending what numbers you are taking for full scale signal), up to what bandwidth this values is measured, is this measured from bit cell to bit cell or frame start to frame start, or is this a FFT of the jitter. So 500 ps alone does tell nothing.

 

About the audibility of jitter, most of the different AES (Audio Engineering Society) articles I have read, attend and listen to, went into a similar direction (not all the same, but similar). Malcolm Hawksford has hold an very good AES session about jitter, where he played back the music with different kind of jitter and also removed the original content and left only the jitter content to listen to, in deed, very interesting.

 

Most jitter numbers are given as RMS values (so also with the school book orientated calculation), but the numbers I have given at the above mentioned post (this post came from) with for example 2.5 ps are the FFT values. And for all the maths out there, you can only compare these numbers with the RMS number if you take the conversation factor (with window scaling and at most the bin width) into account. (I used 44.1k sampling, 16K FFT with equiripple window (2.63 bins scaling)). So if I would have integrated over all of the 16K bins, I would end up in about 900 ps Jitter RMS when measuring in broadband up to 100 kHz.

 

But as I told at the very beginning of this post, only the value of this number does give me no insight about the kind of jitter, so I gave up just looking at this number. I am doing an FFT analysis and try to understand, what correlates with the sound. And I use the expression “try to understand”, because we are far from saying, that we do understand what we are hearing, we are all trying to learn to understand.

 

Juergen

 

PS: Sorry for my bad English, but I am not native English and also have not the time to read and correct my writings, until it is fluid.

 

 

Link to comment

... Juergen - thank you for bringing clarity to the discussion of jitter here on CA. Your english is very understandable, clear and concise. Don't worry about it too much, OK? .... Please just keep doing what you are doing! You have my full attention.

 

Thanks again!

-markr

 

Link to comment

Gang,

 

Just a few things as I have spent allot of time over the last five years looking at this.

 

Another good article is the TN23 article also by Julian Dunn, available on the AP site as well. This tells you how to measure side band info like John Atkinson uses and develop a number based on these.

 

Presently we have 4 companies who make High End Audio testing equipment. Audio Precision, Miller, Prism and Stanford. Only Miller and Stanford actually give use a numerical value. Prism and Ap basically say it is too hard to give a number by measuring side bands.

 

The other way is open the box and use a Wavecrest DTS system which is the unit that every oscillator company in the world uses to measure jitter.

 

About 8 months ago I got the Wavecrest and have had the Prism for a couple of years. I bought the Prism for two reason's it has the best and deepest FFT analysis of any of the above and also because it is the only device capable of natively testing computer dacs and adcs.

 

With the Wavecrest you can basically measure any clock for jitter down to about less then 0.5pS.

 

An interesting thing happened when I was testing with both units. I found you could not fix jitter. For years you heard of people removing jitter from SPDIF inputs and now Firewire and USB with the use of upsamplers or reclockers. Well actually both of these methods merely reduce the jitter they cannot remove it and the more there is the more that get's through.

 

I first thought this true with some of John Atkinson's testing when a dac had multiple inputs. Most of the companies said that their jitter removal made all the inputs the same. Well in testing that did not prove to be the case.

 

I did some tests with my dacs and some of the others sitting around with the Wavecrest centered on the Word Clock WCLK. We use the Word Clock as the reference because it will have the worst jitter component of any of the 3 clock signals of Digital Audio (Master Clock MCLK, Bit Clock SCLK/BCLK). This is mainly because with each division of any clock the jitter goes up and the Word Clock is derived from the Master Clock/256. Ok... I planted the Wavecrest on the input and the output of some of the upsampler chips and sure enough with some SPDIF inputs the jitter (all done at 44.1) were between 512ps (Cirrus/Crystal) and 627ps (AKM) using the one with the best results. [FYI SPDIF streamed from Prism dScope III output] The output of the upsampler was only 69.02ps. This because it was derived by a new clock which would have better jitter than say one derived from an SPDIF input. I did the same using the TAS1020 and Adaptive interface which used the internal PLL generated clocks and we ended up with a result of 2838pS. [uSB using the Prism dScope III software Vista Pro 2.4GHZ Core 2 Duo, 4GB Memory, SSD128GB] The output of the upsampler was again 69.02pS. So now we move over to the Prism and using the TN23 from above the SPDIF Jitter came out to 173pS using sidebands but the USB ended up being 296ps of jitter.

 

WHY? in both cases the Word Clock jitter into the dac chip was only 69.02pS.

 

I think the damage was done and not recoverable on the input to the upsampler. This would be the same for any anti jitter device.

 

To further look at this we sent some details out and measured some devices using Phase Noise. This is actually a better aspect for testing jitter than using the Wavecrest but it get's hairy as you need some real quiet environment. But you can actually test jitter at specified frequencies. The lower the better when it comes to true jitter. Like if someone says they have 2pS of jitter at 1KHz... well that's no big deal. If they say that it has 2pS at under 10Hz then they have something to say. The results found that actually the jitter using Adaptive mode was mainly caused by the protocol itself and the phase noise would not correlate to a linear jitter. The jitter from the SPDIF was correlated and mainly due to the rock solid output of the Prism dScope III and would not be the same for some transports.

 

In looking at the Adaptive mode output using spectrum analysis (12bit 10MHz sample rate Pico 3224 v6 software) we found that three things came into play for it's performance: 1ms timing of Adaptive mode, PLL generated clock, power supply noise. In the TAS1020 code the output clock is changed every four 1ms periods. This was pretty evident by the spectrum analysis. The PLL noise was actually allot higher and I feel this jitter would be removed by either an upsampler or a reclocker. The power supply noise especially what we call the 1/f noise will always lead to jitter in the system.

 

SPDIF part 2... Ok what about the jitter coming out of the computers. I tested a MacMini and a MacBook TOSLINK output into the Prism dScope III along with a spectrum analyzer and found these to suffer allot in the area of PLL generated clock noise and also what looked to be noise similar to the Adaptive jitter. Jitter from the Mini was 1607ps and from the MacBook 1103pS. I almost think the drop considering they have the same chip set was due to the speed and capabilities of the computer (MacBook 2.4GHz, 4GB, 128SSD it's a dual boot same as used above, Mini is a 1.6GHz, 2G, 320gB).

 

Anyways the point of all this is that we need to keep the jitter down from the beginning and not try and fix it later. That just does not work.

 

Thanks I have to get back to work now.

Gordon

 

Link to comment

Hi Gordon, nice that you dig in with some additional comments. I originally didn’t want to go too deep into these points at this forum, and I wouldn’t have gone so far, if I wasn’t asked by “The Well Tempered Computer”. But you continued ever deeper into it, so I just want to drop my agreement.

 

Back in the early years of measuring jitter in digital audio I had begun with the LIM Detector from Ed Meitner, which gave same first insight. Then I continued with the HP Frequency Counter, similar to Standford Research, which gave some insight in the time distribution of different clocks.

 

But for me the most progress was done with the Miller Suite, using the J-Test Signal from Julian Dunn, and analyzes each sideband. This is on the analog side, IMO the best method to measure the Jitter. This can also be done with the HpW Works software, but without the numerical results.

 

But as I told in this post, I (or we) are still learning. At this moment for me I was looking to detect weather a digital receiver has a fractional clock divider (as the Wolfson 8804 has). This sounded a little be like SRCs do sound, but SRCs I can detect and they aren’t bit true, but fractional clock divider, I can’t detect and they look but true, because the “working” only on the master clock.

 

Let’s see, what the future brings. One other thing, I would like to get in contact with you directly concerning a different issue. So will you get my email, if I contact you via the main email address of your Wavelength Audio Company or what would be the best way to get in contact with you?

 

Juergen

 

 

Link to comment

Gordon, great that you shared. Thanks.

 

It would at least prove that my own DAC, rated at 2ps or so after the SRC indeed sounds a hell of a lot better with I2S opposed to SPDIF.

 

It would also prove that when the jitter is variated at the input, it is audible at the output anyway.

 

So, nothing new for observations I guess.

 

Gordon, any chance you can get me on the starting tracks for the abouts with phase noise ?

The way you did it, is it written down somewhere perhaps ?

Test files to load into the PC ?

 

I own a dScopeIII just bought for these matters, and I am ready to invest a whole of a lot of time in it.

May it help, I developed a 3D local positioning system (like GPS) for ultrasound, as well as simulation software for the same with lightwaves (0.1mm precision). So I'd know everything about phase shifts and what to do with them. But this is the other way around and it is not (happening) in electronics.

 

Please let know whether you rather do this by email, if at all.

 

Anyway, again, thanks for sharing !

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Gordon - and Juergen,

 

It may seem strange but the geek in me (and I think, lot's of the rest of the CA population) is really into this thread. I cannot thank you two enough for taking the time to expand on this subject. No pressure. Just let it flow, when it flows. I want to LEARN! -- What Roseval asked.....

 

- markr

 

Link to comment

"I'm very curious to know what the jitter specs are when Adaptive mode is replace by Asynchronous."

 

This is entirely depend on a lot of things:

 

- The PC clock

- The TAS1020 clock and loop filter

- The implementation of board, power supply, transmission-lines and terminations etc. etc..

 

There is no simple answer to this. Either one can be very good IMO. I have async using my Pace-Car and synchronous using my Off-Ramp.

 

Steve N.

 

Link to comment

We are talking technology so implementations.

You can’t measure if there isn’t a full implementation.

I’m pretty much aware of it.

 

We are talking technology so there are many ways to Roma.

In this case I’m interested in the asynchronous way.

It is a new way (Gordon and dCs are the only ones who have developed it up to now) and I’m curious to know how it compare to adaptive mode.

The switch from synchronous to adaptive mode was made to reduce the jitter and it worked. Maybe asynchronous mode offers likewise improvements.

If it does, it will make adaptive mode as obsolete as synchronous mode

 

BTW: one can do the comparison in an almost identical setup: http://www.usbdacs.com/Concept/Concept.html

 

Link to comment

...discussion is going nowhere. I don't think anyone has ever proposed that jitter doesn't exist or that it can't be measured. The only question, really, is whether or not it is audible in most gear, therefore necessitating its further reduction, and justifying that reduction's cost.

 

Have any of the manufacturers/developers/enthusiasts in this discussion ever conducted objective (ie: blind) listening tests that clearly demonstrated that a difference could be heard, beyond the margin for error, in exactly the same system with any of this advanced jitter reduction technology being used? No subjective judgment, no evaluation, just the simple clarity of discovering if the blind listener can identify the device in the signal chain.

 

Before you object with the comfort of the listening conditions and the sophistication of the listeners arguments, have you conducted such tests under the conditions you think are appropriate, with listeners you believe are sufficiently sophisticated? Do you have plans to do so? Will you publish the results of those tests here and on your websites, regardless of the outcome?

 

Tim

 

I confess. I\'m an audiophool.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...