[pbrstreetgang]

Here are some more Jitter measurements of various components All from Stereophile

Bel Canto Dac III "An enormous boost in the noise floor can be seen on either side of the tone, and the measured jitter was 3030 picoseconds (ps). However, though this measurement was repeatable, I am not sure that it really shows what is happening. You can never eliminate the possibility that there is some strange interaction between the device under test and the test gear"

Nagra DAC "Driving the Nagra DAC with S/PDIF data from a PS Audio Lambda CD transport gave a measured jitter level of just 140 picoseconds peak-peak, which is superbly low."

MBL DAC 1611 "The weighted sum of the jitter components was 361.5 picoseconds peak–peak—a little higher than I'm used to seeing these days from top-quality DACs and CD players."

Musical Fidelity kW DM25/ DA25 DAC "The measured jitter level is 394 picoseconds peak–peak—low, but not as low as the best products I have measured.

PS Audio "The optical connection reduces the measured jitter from 321 picoseconds to a low 179ps, and eliminates all the narrow noise spikes in the spectrum"

[Geardaddy]

The Nagra DAC finding is interesting.  I wonder what the Lessloss DAC with slaved transport registers at?

[sts9fan]

Picoseconds people 10x10^-12 seconds.  Now if you told me nanoseconds I would be all ears but PICO!!  thats just silly....

[Geardaddy]

Kris, you are here to cause trouble and I approve....

[sts9fan]

In fact I have been thinking on this quite a bit lately.  I run a Squeezebox as my only source and I am pondering my upgrade path.  Do I go transporter then maybe a dac or do I try the Empirical Pacecar and maybe a I2S dac.  I am having a hard time thinking of upgrading a $300 device with 2k+ of goodies. 

[pbrstreetgang]

ditto, I agree the boutique clockers and source mods can get to 3K real fast- just to feed into a DAC!! From EA we can easily do 10K on PC audio

[bpape]

Why don't you get the new Duet.  It'll be much easier justifying $2k of goodies on a $400 device  

Bryan

[sts9fan]

yeah but the remote is $250 of that!!

[art]

what does jitter sound like to you?

Jitter is inaudible because it is typically 120 dB or more below the music, and 20 to 30 dB below the noise floor of a standard CD, which is typically inaudible too. I have no idea why people obsess about stuff like jitter and dither, but of all the things that matter in an audio system - frequency response, distortion, room acoustics, etc - jitter is at the very bottom of the list.

what remedies do you suggest?

I suggest you ignore this non-issue and enjoy the music.

--Ethan

Might I suggest that you stick to a subject that you actually know something about?

Pat

[DevillEars]

Maybe we need to step back and take a look at the processes used to both record music to a digital medium and to subsequently replay music stored on a digital medium.
(Let me just add a caveat that I am no expert in this field and, if there are any inaccuracies or errors, I would really appreciate being corrected)

Some items to remember regarding the recording process:

• Music, as performed, consists of a complex and continuous analog signal
• Music, as digitally recorded, consists of a sequence of discrete numeric values
• The recording process must convert the continuous analog signal into a sequence of discrete numeric values
• The analog-to-digital conversion process achieves this by taking snapshots (samples) at precise time intervals
• The precision of the time intervals is critical to ensure that subsequent digital-to-analog conversion can be accurate
• The number of snapshot intervals (samples) per second is defined as the "sampling rate" (44,100 samples per second for CD)
• Each snapshot is then converted to a numeric value represented using a resolution of 16 bits (giving 65,536 possible values)
• The resulting series of values is then packaged into a standard format (defined by the Red Book standard) and written to disk

Some items to remember regarding the playback process:

• Music, as digitally recorded, consists of a sequence of discrete numeric values
• Music, as reproduced, consists of a complex and continuous analog signal
• The playback process must convert the sequence of discrete numeric values into a continuous analog signal
• The precision of the time intervals is critical to ensure that they "map" 100% to the sampling in the ADC process
• Various DAC technologies use different approaches to reconstitute the analog signal from the 16-bit snapshots

There are two major sources of inaccuracies in this end-to-end process:

• Errors due to data loss (aka bit drop-out)
• Errors due to differences in the timing between original sampling and reconstitution

Ignoring data loss errors as being "off-topic" in this thread, let's examine the issue of errors arising from differences in timing (ie "jitter").

Most graphic examples use a simple sine wave to show how the reconstitution of the continuous analog signal is achieved by "plotting" the discrete sample values against time, usually resulting in a series of "steps" going up and down.  In these examples it is difficult to visualise why timing errors are likely to cause audible "nasties" apart from minor "ripples" in the "plotted" waveform.  Music, however, does not consist of a single frequency sine wave of a fixed amplitude, but rather comprises a very complex mix of wave forms of multiple frequencies and multiple amplitudes all running along together.  If you can picture this, then imagine a timing error that breaks the precise "mapping" back to the original, then the impact of "jitter" can also be understood - as the impact will vary across the multiple and parallel different waveforms.

In the early days of CD and the motto of "perfect sound, forever", most people believed that the only possible source of distortion in the digital record-store-replay process lay in data loss.

One of the earliest companies to recognise that timing inaccuracies (or "jitter") were another source of distortion was the UK-based Trichord Research (then run by Graham Fowler and Tom Evans).  Trichord developed and marketed their Trichord Clock upgrade which basically replaced the stock crystal oscillator (or "clock") in a CDP with a high accuracy (typically 5ppm) crystal oscillator. Trichord continued to develop and evolve this concept through later iterations (Clock II, III and IV).

Back in the mid 1990's I had a Rotel RCD965BX CDP and decided to try out the Trichord Clock II variant available at the time.

The result was a clearly discernible improvement in detail retrieval and spatial cue reproduction (staging and imaging) plus a very clear improvement in clarity at both frequency extremes.

This approach of fitting a more accurate clock was Trichord's approach to "fixing at source" (aka "prevention").

Paul McGowan - now of PS Audio fame - developed a slightly different approach with the Genesis Digital Lens which fitted between the transport and the DAC and was designed to "eliminate jitter" (aka "cure").

Both approaches - prevention and cure - were effective in improving sound quality in the digital replay chain - as attested to by many a reviewer and consumer.

These improvements were all achieved though the reduction of jitter.

So, I would tend to argue against anyone saying that jitter induced errors are undetectable audibly!!

[art]

Picoseconds people 10x10^-12 seconds.  Now if you told me nanoseconds I would be all ears but PICO!!  thats just silly....

No, just your response.

I don't understand how any of you people can make claims about jitter not being this, that, or the other thing, without stating magnitude, frequency spectrum, or level of data-correlation.

The bottom line is that depending on all of those 3 criteria, jitter can be problem in any system. Its causes are many. Anything from SPDIF, which is a joke, to CD players that stick the clock circuit in the digital filter chip. Just because some people of dubious reputation make products to address this issue is no reason to dismiss it as another "solution" looking for a problem to fix.

Pat

[pbrstreetgang]

If you are talking to me then I have no fight one way or the other. The numbers are all from Stereophile under the same testing procedures and while you are right they mean nearly nothing as stated but are represented when compared to the same measured number to a different and know "other" piece.

[art]

Nope.....someone else.......

A few posts managed to sneak in while I was composing my thoughts.

Pat

[TRADERXFAN]

Pat,
As an interested observer, -If the SPDIF is so bad, what is good? 
I2s?
AES/EBU?

I have recently bought a behringer deq2496 and it discusses how the AES input already has some kind of synchonicity with other AES devices and so the wordclock input is unused. Does that equate to jitter-reduced playback?

Thanks,
Tony

[AphileEarlyAdopter]

..  I got a Pace-car from EA to slave the Squeezebox.  It's not an atomic clock but a Super Clock 4 is probably better than the one in an SB3 if only because it would have an external PS.  Anyway, when comparing the sound through my DAC (Northstar 192) I can hear a difference between music reclocked with Pace Car vs. music steamed out of SB3 directly to the same DAC using SPDIF.  ..

I envy you for this perfect (IMO) setup. I wanted to get the Pace Car but I would have to use the SPDIF with my Panny xr55. Maybe, it will still make a difference.
Is that you or somebody else who is going to compare the SB3/Pacecar with the Bolder Digital Modded SB3 ?
(BTW, those who think jitter is inaudible - you are going to be on a merry go around chasing for the perfect sound (like changing DACs/preamps/ICs etc) , if you do not try to fix this issue)

[Geardaddy]

(BTW, those who think jitter is inaudible - you are going to be on a merry go around chasing for the perfect sound (like changing DACs/preamps/ICs etc) , if you do not try to fix this issue)

Amen....

[art]

Pat,
As an interested observer, -If the SPDIF is so bad, what is good? 
I2s?
AES/EBU?

I have recently bought a behringer deq2496 and it discusses how the AES input already has some kind of synchonicity with other AES devices and so the wordclock input is unused. Does that equate to jitter-reduced playback?

Thanks,
Tony

I2S should be better, but now you have to move 4 data steams from Point A to Point B. How do you do that? One cable? What kind of connector? Levels? Logic level will generate serious EMI.

OK, so you go with LVDS. Ought to work OK. Then you need to have a TX chip and a RX chip stuffed into your gear. Do you really think the high-end industry will ever agree on a way to do this, and get it right?

My bet: not likely to happen, unless you make your own. (You could just buy a CD player, as that is what it uses inside.)

AES/EBU.......really just SPDIF with a different connector. Debatable which connector is worse.

Easy to solve: Master clock to every device. Problem solved. Ok, the Pro Audio market figured it out. But how likely do you think the high-end biz is likely to do that? Same answer as before: do it yourself or forget that it will ever happen.

One option is aftermarket modders will come up with schemes to replicate that. Would involve changing CD player and outboard DAC. Potential for some decent folks to make $$$$$$$. Potential for boobs to take your money and butcher your gear.

Don't know about the particular unit you mention. Some Behringer stuff has ASRCs inside. That acts as a PLL, but in the "digital domain". Largely eliminates jitter, but the method is not without controversy.

Did that answer any of your concerns?

Pat

[NewBuyer]

...ASRCs inside. That acts as a PLL, but in the "digital domain". Largely eliminates jitter, but the method is not without controversy...

Very interesting thread here. I've wondered about ASRC's: Wouldn't jitter/timing issues received at the ASRC chip just get remapped to a different rate (i.e. garbage-in/garbage-out)? Like how a hi-res photo of a low-res photo, still looks like the original lo-res photo.

Also, how important is jitter performance compared with the contribution of the other electronics in the source. Granted they are all connected and affect each other, but would it make more sense for source manufacturers to focus on improving the power supply, output stage, etc first? For instance using a discrete opamp instead of an IC opamp, using Jung super regulators, etc - without sole concern for jitter improvement but rather for the contribution these mods alone are thought to bring to analog delivery.

I also have read much about how all jitter isn't the same, that different "types" have different sonic consequences (whatever those consequences might actually be). Some designers have suggested that certain types of jitter might actually be euphonic as well.

Personally I hope the latest generation of soundcard/player-software combos, and also the essentially ethernet-dacs (with server software control) like the Transporter, SB3, etc will make permanent headway into the jitter-busting fight - since ethernet is pulse-transformer isolated, and since the ethernet device depends on its own clock instead of S/PDIF timing.

I have no idea what the answers are - just wondering what others think. 

[art]

"Remapping" is one to describe what happens. I am not sure that I would go that far to quantify its effects, though. The main concern that some of us who build this stuff has against ASRCs is that they are not "bit-perfect". If you are trying to build a machine that can decode HDCD, then forget it.

Use a discrete op-amp...........c'mon......how much space and money do you think the guys who designed the SB3 have to work with? Better power supply.......sure. Does not have to be a JSR, but once again, it takes space and costs money. (For $300, they did a good job. OK, the wall warts are cheesy and they could separate the internal supplies some. But.........$300!)

in the case of the SB3, it would not have taken a lot of money or space to lower the jitter. Well, that is today's line, and I am sticking by it. (See related thread in some other circle.) We will see how right I am very soon.

Pat

[AphileEarlyAdopter]

.. I've wondered about ASRC's: Wouldn't jitter/timing issues received at the ASRC chip just get remapped to a different rate (i.e. garbage-in/garbage-out)? ..

Personally I hope the latest generation of soundcard/player-software combos, and also the essentially ethernet-dacs (with server software control) like the Transporter, SB3, etc will make permanent headway into the jitter-busting fight - since ethernet is pulse-transformer isolated, and since the ethernet device depends on its own clock instead of S/PDIF timing.

I have no idea what the answers are - just wondering what others think. 

I think ASRC creates an output with theoretically a different (and possibly) better clock. Lets take an example, if you rcv a 44.1khz stream and convert it to 88.2khz. A sample value is held for 1/44100 of a second and during that time it is resampled twice to generate the 88.2khz output. Note, the clock used for output is different from the input so input clk jitter is not retransmitted. Meanwhile, since a sample value is valid for 1/88200 of a second which is much greater the jitter spectrum (say in nano or pico seconds) then jitter has been reduced to a much lesser frequency. (It is also possible jitter might add up and shift the values a bit) But in reality the receiver and the output clock may not be great to provide any real benefit. (this is the best explanation I could muster on this subject. Personally, I prefer using a very good clock at the source, say in a squeezebox and favor the approach used by Empirical Audio in their Pacecar reclocker).

Actually, main advantage with PC or devices like Squeezebox is that their electrical design is simple enough to reduce power supply related jitter.  (nothing to do with ethernet etc as you seem to confuse yourself with).