Most journals actually charge authors, so it’s even worse than that. This is why I have no guilt whatsoever about using sci-hub.
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Understanding Jitter in Digital Audio: Measurements and Listening Tests
- Thread starter amirm
- Start date
- Joined
- Apr 24, 2019
- Messages
- 1,501
- Likes
- 2,834
If I dig deep enough I think I might be able to find the DVD collection of IEEE papers (it will be everything but the last 10yr. or so), you are welcome to it.
I take it that S. A. Wurcer on IEEE is you. Interesting. Years ago I've used some of your figures from a conf paper entitled "Recent Developments in Bipolar Operational Amplifiers" for an undergrad course presentation I used to teach (analog circuits in which I've used the 741opamp as an example).
Yes, it's himself, designer of the famous AD 797 I use in my DIY MC phono preamp in the 1st stage. Thanks to @scott wurcer!
dougi
Addicted to Fun and Learning
I was an IEEE member for many years but you still had to pay for every conference paper, rather than journal articles within your scope. Of course, half the stuff you wanted to research was in the conference papers! I stopped being a member when I joined an organisation with an org wide subscription.
Jitter is not a magic word to get digital cables and interfaces, between DAC's and sources matter. If you keep the CD players in one unit, it should have no Jitter at all. When an external DAC (to the player) is used, it has to deal with a serial signal called SPDIF (Sony Philips Digital Interface), that is set by STD as a PCM data (16 bit + 1 for error correction), of both channels (2) at a 44.1 kbps, in a bi-phase signal, that carries the data with a clock.
Jitter is valid (and measurable) when that clock and data gets misaligned by some time. If that time is less than 50 pSec. the jitter is inaudible.
ALL DACs have a circuit called PLL (Phase Lock Loop) that should overcome that time misalignment between data and clock. Some are better than others.
Today PLLs should all be way better than required to overcome audible Jitter inflected THD+Noise. The idea is that a well designed and implemented DAC should not sound nor measure different when it's cable (COAX or Optical) is exchanged!
The blind search for a good sounding cable is a blind shot in the dark, while what should be taken care of is actually the DAC or it's poor PLL design.
In 2021, jitter should be no more an issue. Excellent PLL IC's are on the market for no much money, that using one, should eliminate the problem.
Unfortunately, many audiophiles are not having the engineering background to understand the technical definitions (jitter), what cause them, and how to fix it. What would guide them (wrong) are sales people, that have a different agenda ($$$) than clear and fix the issue.
On the same level speaker cables are chosen by all the wrong reasons, at a time they are gett significant as the Amp's DF rise, and they should be properly calculated and built/ordered accordingly. The industry is mostly providing thin cables (#12-14 AWG), because they can fit easily into a banana plug or spade. however, as they, nor the audiophiles have a clue of that relation (cable cross section vs length and DF), they flood the market with BS and snake oil. Some are ridiculously nonsense. Directional is the best. But there are so many more.
Jitter is valid (and measurable) when that clock and data gets misaligned by some time. If that time is less than 50 pSec. the jitter is inaudible.
ALL DACs have a circuit called PLL (Phase Lock Loop) that should overcome that time misalignment between data and clock. Some are better than others.
Today PLLs should all be way better than required to overcome audible Jitter inflected THD+Noise. The idea is that a well designed and implemented DAC should not sound nor measure different when it's cable (COAX or Optical) is exchanged!
The blind search for a good sounding cable is a blind shot in the dark, while what should be taken care of is actually the DAC or it's poor PLL design.
In 2021, jitter should be no more an issue. Excellent PLL IC's are on the market for no much money, that using one, should eliminate the problem.
Unfortunately, many audiophiles are not having the engineering background to understand the technical definitions (jitter), what cause them, and how to fix it. What would guide them (wrong) are sales people, that have a different agenda ($$$) than clear and fix the issue.
On the same level speaker cables are chosen by all the wrong reasons, at a time they are gett significant as the Amp's DF rise, and they should be properly calculated and built/ordered accordingly. The industry is mostly providing thin cables (#12-14 AWG), because they can fit easily into a banana plug or spade. however, as they, nor the audiophiles have a clue of that relation (cable cross section vs length and DF), they flood the market with BS and snake oil. Some are ridiculously nonsense. Directional is the best. But there are so many more.
You are talking about the engineering background, that you seems to have. May I ask how you set the treshold of audibility on jitter (or distortion caused by jitter) to 50ps? Legit question, not a dismissal.
About the “no jitter at all” of CD players. mmm, well maybe according to the said treshold. Any clockinng system has a tolerance, this tolerance can be converted to Picosecond, or femto seconds, but you’ll never reach “no jitter at all”, you can certainly get negligible jitter tough. To this a USB connection is pretty much immune to input jitter, I get what you mean about cd players, but, as usb, it’s not immune to intrinsync jitter. your example of spdif,, or it’s various flavours
(aes/ebu, toslink), is kinda true, but it’s just a feature of synchronous transfer, no absolute input jitter immunity.
- Joined
- Feb 23, 2016
- Messages
- 22,695
- Likes
- 41,870
B4icu can answer of course. I seem to recall that for redbook, 50 picoseconds is the timing accuracy of 16 bit 44.1 khz. So less jitter than that and you aren't effecting the timing accuracy of 16 bit 44.1 khz. So there is no possibility of this being audible as it wouldn't change any output waveform timing accuracy.
That wouldn't mean just over 50 ps is audible. Only that lower than this cannot be audible. Chances are with music as in Amir's video, jitter is only audible at higher nanosecond levels or certainly more than a nanosecond.
The bottom line is, jitter was already a solved problem audibly when it first became known by the public. So just don't worry about it. It is a non-issue.
Just to be clear, from this reasoning, 50 ps is the treshold to avoid a bit flip? And if so, legit question again, is the only thing we should worry about is the integrityof the transferd samples? then the timing at wihich they are converted is not a significant metric?
- Joined
- Feb 23, 2016
- Messages
- 22,695
- Likes
- 41,870
Well no, because you can't have jitter in stored data. Jitter only happens when data is clocked out. However, in practical terms, jitter during the clockout is not a problem, so integrity of data is a thing. And that too is a solved problem. Lost or corrupted bits isn't explaining any of the audiophile subjective perceptions of digital audio.
USB connected DACs use a free running crystal clock for clocking out. And that is the cleanest and best way of timing because you aren't slaving to anything else in terms of timing. Doesn't mean the clock is jitter free, but it is very, very low jitter.
Jitter related THD+Noise, as any other cause of such artifacts, have an audible limit. Even though Mr. Amir is mostly about measurements, of AP tools (in the 90's I had lunch with AP's CEO at Elbit in Israel), It never came to a say, it has X dB SNR or 0.00N% THD but I can't hear it...Well, our hearing limits are limited, and get narrowed by age and exposure to loud noise sources. I assume that the majority of the audiophile would fall in that category. I do.
I read about the 50 pSec milestone of jitter, in more than one article. I used to own an Audio Alchemy Jitter reducer, with digital in and digital out!
I paid for it $400.- I could get a better use of that money. I shamly admit it was a nice black box that din NOTHING!
For all the guys who think / claim / own golden ears, you better put it first to test at a hearing impaired lab, to at least know where you stand, or what your claims here and thar worth.
I read about the 50 pSec milestone of jitter, in more than one article. I used to own an Audio Alchemy Jitter reducer, with digital in and digital out!
I paid for it $400.- I could get a better use of that money. I shamly admit it was a nice black box that din NOTHING!
For all the guys who think / claim / own golden ears, you better put it first to test at a hearing impaired lab, to at least know where you stand, or what your claims here and thar worth.
Last edited:
Mr. Blumlein, USB (https://en.wikipedia.org/wiki/USB) has a +/- 5V supply and a +/- Data. From where did you came out with a clock on USB interface?
- Joined
- Feb 23, 2016
- Messages
- 22,695
- Likes
- 41,870
The clock is on the DAC chip usually or adjacent to it.
There is clocking on USB or it wouldn't work. 8 khz clocking noise off USB often shows up in noise floors of DACs. But good DACs divorce the USB clocking from the DAC clocking out by buffering the data stream.
https://troll-audio.com/articles/time-resolution-of-digital-audio/
This is a good article on time resolution. You often see actually 55 picoseconds timing accuracy for redbook. Mansr pegs it at 110 ps, and explains why here, and why it varies with frequency. This is what I had in mind.
Mr. Blumlein
https://www.electronicdesign.com/te...ticle/21801786/achieving-bitperfect-usb-audio USB has no clock over data, as it is a single differential communication interface. the clock is generated by an I2S codex device that outputs from the USB (in) a clock and data.
The USB itself is data only. No clock...SPDIF on the other hand use a biphase methode to integrate clock and data (single ended!) which is processed in the receiving device (DAC) to separate the two. The clock use a PLL to synchronize the two: Data and Clock, hopefully to better than 50 pSec.
Any problem of that PLL or codec, to keep jitter under 50 pSec. may give the cables the liberty to impact sound quality.
If the above is well implemented, it seems that a shoe lish would do, if it could conduct...
https://www.electronicdesign.com/te...ticle/21801786/achieving-bitperfect-usb-audio USB has no clock over data, as it is a single differential communication interface. the clock is generated by an I2S codex device that outputs from the USB (in) a clock and data.
The USB itself is data only. No clock...SPDIF on the other hand use a biphase methode to integrate clock and data (single ended!) which is processed in the receiving device (DAC) to separate the two. The clock use a PLL to synchronize the two: Data and Clock, hopefully to better than 50 pSec.
Any problem of that PLL or codec, to keep jitter under 50 pSec. may give the cables the liberty to impact sound quality.
If the above is well implemented, it seems that a shoe lish would do, if it could conduct...
- Joined
- Feb 23, 2016
- Messages
- 22,695
- Likes
- 41,870
We are saying the same thing. A serial interface must have a clock. But USB that clock is data only. Nothing to do with clocking out audio data. That is done with a free running crystal which yes may connect to the DAC chip over I2S or not depending upon the design.Mr. Blumlein
https://www.electronicdesign.com/te...ticle/21801786/achieving-bitperfect-usb-audio USB has no clock over data, as it is a single differential communication interface. the clock is generated by an I2S codex device that outputs from the USB (in) a clock and data.
The USB itself is data only. No clock...SPDIF on the other hand use a biphase methode to integrate clock and data (single ended!) which is processed in the receiving device (DAC) to separate the two. The clock use a PLL to synchronize the two: Data and Clock, hopefully to better than 50 pSec.
Any problem of that PLL or codec, to keep jitter under 50 pSec. may give the cables the liberty to impact sound quality.
If the above is well implemented, it seems that a shoe lish would do, if it could conduct...
wyup
Active Member
Ok, now it gets interesting.
How does stability and cleanness of the stream of clocked usb bus data affect reconstruction by an asynchronous external usb dac?
@amirm How does upsampling of spdif signal, as done by ESS or more recently Cirrus Logic on Topping D30Pro, work to eliminate jitter? Doesn't it introduce artifacts by its own upsampling algorithm? (I.e: 44.1KHz to 96Khz on ifi and wyred4sound spdif reclockers).
And PLL, does it work with usb async or also with spdif? Because if spdif has its own clock and the dac adapts to it, are we limited to its accuracy or the dacs clock accuracy? I'd wish to understand PLL/clock oscillators and async usb/spdif relationship. And back to upsampling, isn't the signal upsampled afterward aswell for filter reconstruction or to push noise to higher inaudible band?
Sorry for the mingling of concepts.
The USB data interface uses a self-synchronising NRZI coding. S/PDIF uses biphase mark coding which needs higher analogue bandwidth for the same bit rate, but otherwise the concepts are similar. The difference is that the USB interface clock is independent from the audio clock whereas with S/PDIF they are synchronised. To create a USB DAC with low jitter, all one needs is a half-decent crystal oscillator. With S/PDIF, things get a little more involved. The receiver has to synthesize a high-rate clock, typically 256x fs or more. This involves a PLL, and even if the incoming data stream is completely free of jitter, some will be created here. How much depends on the PLL design, which also determines how well jitter from the input is suppressed.
What is that supposed to mean?
Where did you get that figure? The audibility threshold for jitter depends a lot both on its nature (random, periodic, data-dependent) and on the signal. 50 picoseconds (or did you mean parsecs) measured in any of the usual ways is indeed likely to be inaudible, but so is 500 ps.
OK, so what would be the proper term for master clock fluctuations at the DAC end? What you mean by can’t have jitter for “stored” data?In UAC 2 data is buffered, does it qualify for “stored” Can you explain why it would only happens when data is clocked out? Then USB would have no jitter. In amirs reviews, we see better jitter performance for USB vs spdif synchronous transfer, but we don’t see no jitter at all.Not talking about audibility here, just trying to understand the concept s in your statement
Mr. Blumlein
https://www.electronicdesign.com/te...ticle/21801786/achieving-bitperfect-usb-audio USB has no clock over data, as it is a single differential communication interface. the clock is generated by an I2S codex device that outputs from the USB (in) a clock and data.
The USB itself is data only. No clock...SPDIF on the other hand use a biphase methode to integrate clock and data (single ended!) which is processed in the receiving device (DAC) to separate the two. The clock use a PLL to synchronize the two: Data and Clock, hopefully to better than 50 pSec.
Any problem of that PLL or codec, to keep jitter under 50 pSec. may give the cables the liberty to impact sound quality.
If the above is well implemented, it seems that a shoe lish would do, if it could conduct...
As others have said, 50ps jitter is inaudible. You can inject jitter into an existing music file and listen to it with my DISTORT app. I can rarely tell the difference even with hundreds of nano-seconds jitter (correlated or not). Try it with DISTORT, and you can judge for yourself.
- Joined
- Feb 23, 2016
- Messages
- 22,695
- Likes
- 41,870
I can have all the bits written on a piece of paper or statically stored on a disc. There is no jitter in data. The jitter comes from clock perturbations upon playback as it is a real time dynamic effect. So as jitter basically is a sample reconstructing too early or too late such time has no meaning for the stored sample data. It can only be early or late as it is played back and clocked out.
Now even a free oscillating crystal isn't purely jitter free. Plus various other noises can get in to alter exact timing upon playback depending upon design. Yet these can only occur during actual playback and are a fluctuation in the clock and not anything in the data itself.
Oh, I forgot that Pkane's Distort also does jitter. You should give it a try.
Similar threads
