Jitter stew

[alfe]

..

 

[RayDunzl]

Any thoughts ?

Environment probably swamps most electronic oddities.

First, turn off the ceiling fan...

http://audiosciencereview.com/forum/index.php?threads/close-in-jitter.1621/page-15#post-41686

 

[Blumlein 88]

My thoughts would be jitter is only audible at levels much higher than almost any piece of recent gear displays. Some bad HDMI implementations might get close to audible. Jitter will manifest itself as sidebands and noise. As much gear has very low levels of both I would think effects will be masked by the signal.

So alfe, what do you have to say about jitter? Think it is an audible issue? If so do you think close in jitter the problem some have claimed or something else?

 

[Blumlein 88]

Okay alfe.

So how about posting a bad UI stew and a good UI stew, and discuss as much as you can about what the effects would be in one case vs the other.

Or is there a better way to approach what you have in mind?

 

[Wayne]

alfe,
I do not understand the chart/graph you posted above (see Reply # 5). Could you give us some information such as the instrument used to make the chart/graph, and where one can get additional information on interpreting the results.
Thanks

 

[The Smokester]

That is an "Eye Diagram" used to display the spreads in triggering waveform heights and shapes and the resulting variation in trigger timings=jitter. See here:
http://www.edn.com/design/test-and-...gram-Basics-Reading-and-applying-eye-diagrams

 

[Wayne]

Thanks Smokester. The reference was "Eye Opening" Interesting, but over my head technically.
.

 

[Fitzcaraldo215]

Audibility is the question. Nice eye patterns are all well and good, but I am not going to pay inordinate attention to them. Much more important are the differences in measurable output from the DAC and in human perception in double blind listening. How exactly do eye patterns correlate with that? Not well, I venture.

Jitter keeps popping up like a zombie rising from the grave every night. Somebody would really have to work very hard to convince me it is still an audible problem in the era of highly buffered, asynchronous USB.

 

[Cosmik]

It should always be emblazoned in large letters that jitter is *irrelevant* if the system is asynchronous and packet based (could be asynchronous USB, ethernet, Bluetooth, WiFi, etc.). Eye diagrams and all the talk about jitter is completely misplaced if the system is packet based.

This, it would seem, is not understood by most people.

The difficulty for this clean, perfect idea and argument is that of course in the real world the elimination cannot be 100% perfect; merely 99.9999999999% and that the 0.0000000001% although not measurable (see every Archimago article with measurements, just about) *must* be there to some extent - and audiophiles will claim to be able to hear it.

Further confusion arises with non-asynchronous systems that *are* affected by jitter but, depending on how it is handled with PLLs and latency, can have the effect suppressed greatly. These could be isochronous USB, S/PDIF, etc.

If there is sample rate conversion in the system, this also adds to the 'stew' of confusion.

Really, for domestic hi-fi, there is no need for this confusion. The DAC should set the sample rate so no sample rate conversion needed. The DAC should demand the data in packets as it needs it, thereby *eliminating* the effects of jitter. The original CD players from the 1980s effectively did this!

Instead, people create ridiculous Heath Robinson systems with one interface feeding another, upsampling, then being 're-clocked' and so on.

 

[amirm]

There is another aspect to this that is not intuitive. Lower jitter may be audibly worse than higher jitter! Reason is that we can tolerate a lot of random jitter because it translates into higher noise floor. Replace that with lower jitter but deterministic, i.e. related to the signal or on its own and that may be more audible.

This is why we examine the spectrum of jitter coming out of DAC. It is the spectrum that is first and foremost important. We can compare that to threshold of hearing, masking, etc. and determine likelihood of audibility.

 

[amirm]

Thanks Smokester. The reference was "Eye Opening" Interesting, but over my head technically.
.

I tried to find a simplified video of it but could not as they are all done for engineers.

Here is a simple analogy. Imagine I demand 100% ontime arrival at 8:00am for employees. Now, every time someone arrives, I put a tick on a line that shows time. I do that for days. After that, the line will have lots of ticks on it. If everyone is on time, all the ticks will be at 8:00am and rest of the line is empty/clean. If people are not on time, then ticks will be spread everywhere.

Same is true of "eye pattern." The pattern is simply the time domain waveform of pulses accumulated over time. If they all land on top of each other (more or less), then the arrival times are all pretty accurate. If they "jitter" back and forth, not so much.

Here are some graphs showing that:

By definition then, the space or blank area between pulses gets polluted by pulses that are not on time. The more they vary, the more they crowd the open space between them. That diagram is called an eye pattern.

The eye pattern is supremely important in determining the reliability of a link. The dirtier it gets, the harder for the receiver to recover that signal.

In digital audio and USB, reliability is never a concern since we are dealing with strong signals and short transmission lines. As such, it is a mistake to look at the eye pattern and sweat over it like communication engineers normally do in much more severe cases.

 

[Wayne]

In digital audio and USB, reliability is never a concern since we are dealing with strong signals and short transmission lines. As such, it is a mistake to look at the eye pattern and sweat over it like communication engineers normally do in much more severe cases.

Thanks to amir and Cosmik for the explanation and putting jitter in perspective for audio issues.

 

[RayDunzl]

The CD players in the 80s were asynchronous? good to know.

As a kid, I had put my thumb on the spinning LP to see what happened. LP playback, being "synchronous" gave immediate feedback. So did Dad if he were listening to Tennessee Ernie.

When I first opened up a CD player I just had to repeat the experiment. Nothing happened (at least for a while).

Playback is asynchronous with respect to the short-term spin of the CD. Spin, read ahead, keep a buffer filled, then the clock dribbles collected data through the conversion to analog at a steady rate.

Someone here went on to explain that not a single bit of data on a CD makes it to the DAC, anyway. The data on the disk is not the left-right sample values.

See

https://en.wikipedia.org/wiki/Cross-interleaved_Reed–Solomon_coding

https://en.wikipedia.org/wiki/Reed–Solomon_error_correction

 

[Blumlein 88]

As a kid, I had put my thumb on the spinning LP to see what happened. LP playback, being "synchronous" gave immediate feedback. So did Dad if he were listening to Tennessee Ernie.

When I first opened up a CD player I just had to repeat the experiment. Nothing happened (at least for a while).

Playback is asynchronous with respect to the short-term spin of the CD. Spin, read ahead, keep a buffer filled, then the clock dribbles collected data through the conversion to analog at a steady rate.

Someone here went on to explain that not a single bit of data on a CD makes it to the DAC, anyway. The data on the disk is not the left-right sample values.

See

https://en.wikipedia.org/wiki/Cross-interleaved_Reed–Solomon_coding

https://en.wikipedia.org/wiki/Reed–Solomon_error_correction

You know I have seen things like this before including the idea that after about the 3rd gen CD players, that a CD player has lower jitter than any external DAC due to the SPDIF interface. Except when I measured them with a Jtest signal that generally didn't pan out. I have one old DVD player that will exhibit a tremendously huge amount of jitter whenever you start a disc or change tracks. It slowly subsides over 15 seconds after which it has reasonably low jitter in the output. Maybe it takes 15 seconds to fill the buffer?

 

[RayDunzl]

The master clock may disagree with you.

"There is no master clock." - A. Einstein

 

[Blumlein 88]

Dennis,

You should read my blog in CA about CD playback.

I haven't seen it and cannot find it. Can you provide a link to the blog or was it somehow misplaced in the forum upgrade?

 

[amirm]

The master clock may disagree with you.

Correct in the case of mass market CD players. Regardless of what buffering goes on in the CD player, ultimately the "platter" is the master. The clock that drives the DAC will attempt to sync up to speed of the bits coming from the CD transport and as such, its jitter will travel to the output of the DAC. It is not a complete pass through however. The PLL used to generate the DAC clock will filter the high frequency jitter components subject to its corner frequency. There were also ultra cheap CD players that used the clock from platter directly to drive the DAC (i.e. without the PLL filtering). Example of this was early portable CD players.

There are high-end players that work asynchronously though. Meridian is one example where they use a data grade CD transport just like a computer and essentially rip and play the CD. By the same token, when you play a CD on a computer, the same thing happens. In both cases the DAC clock is fixed and the CD data is read as needed, i.e. asynchronously.

Another solution used by Naim, Mark Levinson, etc. is for the DAC to have constant clock because the DAC "knows" that the source is a CD. Enough buffering is made to allow the DAC to run that way without running out. Overrun is dealt with given the silence between tracks and between CDs.

 

[RayDunzl]

Regardless of what buffering goes on in the CD player, ultimately the "platter" is the master.

From the hazy memory of my experiment, before the era of Data Drives, the platters I saw ran at obviously stepped speeds depending: fast at the center, slow at the edge. Several, not many, steps.

I see no reasonable way those platters were providing clock.

I still have my first drive in the garage. Marantz 3 something? One channel of the analog output was only giving a half-wave (reason for retirement) but it probably still works. I'll drag it out and look again (likely before part 3 of REW for Dummies comes out).

(I get to be wrong, though, not being a member of Audio Royalty)

 

[amirm]

I see no reasonable way those platters were providing clock.

It has to. Imagine if you used a fixed DAC clock. The platter would either fall behind or get ahead of it.

From the hazy memory of my experiment, before the era of Data Drives, the platters I saw ran at obviously stepped speeds depending: fast at the center, slow at the edge. Several, not many, steps.

That's correct but the amount of data also varies per track. Constant linear speed is used in CD (audio).

Edit: corrected the reference to linear speed instead of angular. Data drivers can use constant angular speed.

 

[Blumlein 88]

From the hazy memory of my experiment, before the era of Data Drives, the platters I saw ran at obviously stepped speeds depending: fast at the center, slow at the edge. Several, not many, steps.

I see no reasonable way those platters were providing clock.

I still have my first drive in the garage. Marantz 3 something? One channel of the analog output was only giving a half-wave (reason for retirement) but it probably still works. I'll drag it out and look again (likely before part 3 of REW for Dummies comes out).

(I get to be wrong, though, not being a member of Audio Royalty)

I believe CD spun at 450-500 rpm near the center and 200 rpm near the edge. It also maintained a constant linear velocity rather than working in steps.

Alfe can tell us how it really worked. He'll actually know.