PDA

View Full Version : Jitter... what's that all about then?



Mike
17-11-2009, 19:02
The stuff mentioned about jitter all over the place is often quite amusing. I wonder how many posts contain that stupid(*) word, and how may people who've bandied it about know what it actually is or does? :eyebrows:

In digital audio, should we be taking about absolute jitter, period jitter, or cycle to cycle jitter? etc. Should we be worrying about jitter period or jitter frequency? etc.

Do any of us (including me!) actually understand any of this? Or are we just throwing another 'buzz word' about?

In the interest of starting a possibly controversial discussion, here's a few things I've come across that should get the ball rolling...


Cables can reduce jitter.
Cables can cause jitter.
Jitter can be heard (what does it sound like?)
Jitter can't be heard, so doesn't matter
I'm now going to run for cover! :sofa:


(*) I'm not denying the phenomenon, I just think it's a stupid word! :mental: :lolsign:

Alex_UK
17-11-2009, 19:42
This'll be fun!

:popcorn:

Themis
17-11-2009, 19:48
Well, I will let others comment on jitter on digital audio.

I want to say is that jitter is an unwanted signal variation that affects ALL signal-transmitting protocols. This includes telecommunications, data packet transmissions (including devices like HD) and all communications whatever the protocol (USB, IP, SATA, put-your-favorite-protocol-here).
In high-speed digital streams the clock is never transmitted with the data (for various architectural reasons, including transmission speed). The clock for these signals is calculated by the receiver. It is thus, generated by a special algorithm called "clock and data recovery".

Thus, jitter is NOT a digital audio phenomenon, it has to do with data transmission. It is well known, is measured and (as it is unwanted) it is addressed by the "data consuming" application.

(ok, you can wake up, now ! :lol:)

Mike
17-11-2009, 20:13
Quite right, Dimitri. I'm a telecommunications engineer by trade, which is where I first came across it. The actual word "jitter" I believe did not originate on this side of 'the pond' where we talked in terms of 'phase shift'... Jitter (as an engineering term) was rather derided in fact. I remember offering my interpretation of the word and receiving some rather withering looks!

However...


In high-speed digital streams the clock is never transmitted with the data (for various architectural reasons, including transmission speed). The clock for these signals is calculated by the receiver. It is thus, generated by a special algorithm called "clock and data recovery".

But what about 'synchronous systems' where the data transmission is governed by a single clock? Or is that what you mean by "clock and data recovery"?

Synchronous data transmission is very, very common in telecoms and yet I don't think it happens at all with digital audio. Anyone?

I've heard of high end gear using 'master clock' type gizmo's, but I don't know if this is similar? Either way, they always seem to be high end systems at extraordinary prices. And yet there is a system available the world over which is relatively cheap and can be directly traced back to one or two extremely accurate atomic clocks!

Wonder why no-one's thought of that? Or maybe they have but don't want to miss out on those high end price tags! :confused:

Themis
17-11-2009, 20:46
But what about 'synchronous systems' where the data transmission is governed by a single clock? Or is that what you mean by "clock and data recovery"?
Synchronous systems, just have additional exchanges for synchronizing their respective clocks. In other words, they send some kind of "clock" data separately.
They use asynchronous communications, but they reconstruct (synchronize) their data based on the clock data sent. We use this only on specific critical applications. Synchronization it's too computing-cycle consuming to be used on a regular basis.
Some use 'synchronous systems' as a synonym for 'isochronous communications'. In this case, yes, the system reconstructs the clock from the interval of the data received. It is, indeed, what I meant by "clock and data recovery". To me, they are still "asynchronous" communications (but perhaps I'm wrong?).

At least that's how I see it from a system (consuming) level.

The "master clock" solution (afaik) can be seen as some kind of "synchronous" implementation: it allows to share a clock and thus not having two different clock errors. It doesn't eliminate all timing errors, it justs eliminates "some" kind of errors: the ones due to the differences between the "producing" and the "consuming" clock.
It is a (good) solution. I would have preferred some kind of "logical" layer, like the one used in "synchronizing" systems. The advantage of logical layers is to provide an error recovery. I've allways wonder why the guys who designed the actual audio protocols didn't think of it. Perhaps they were more "hardware oriented" than "software". Pity.
Even the actual audio USB implementation doesn't have an error recovery. :(

But, again, I'm not a specialist in audio communications. There must be some difficulties that I cannot grasp.

Mike
17-11-2009, 21:05
Synchronous systems, just have additional exchanges for synchronizing their respective clocks. In other words, they send some kind of "clock" data separately.



True... but in a highly localised system like a HiFi it should be possible to actually use the SAME clock!

Which, with a little bit of careful application, could completely solve:


The "master clock" solution (afaik) can be seen as some kind of "synchronous" implementation: it allows to share a clock and thus not having two different clock errors. It doesn't eliminate all timing errors, it justs eliminates "some" kind of errors: the ones due to the differences between the "producing" and the "consuming" clock.


And...



We use this only on specific critical applications.


Is, in fact, quite common! :)

Here's a bit of 'light reading' which might get your grey matter working!

Availability of a world-wide accurate clock; http://en.wikipedia.org/wiki/Global_Positioning_System#Signal_arrival_time_meas urement

Where I get my ideas about 'synchronisation'; http://en.wikipedia.org/wiki/Synchronous_Digital_Hierarchy

*WARNING* You may suffer 'rapid onset narcolepsy'! :lol:

Mike
17-11-2009, 21:25
HeHeHe... we seem to have gone strait to discussing 'off the wall' possible solutions here!

What about the JITTER?... c'mon ya b'stards! What is it?, What causes it?, What do we do about it?

What about "jitter reducing cables"?... I've seen quite a few claims for that one! As well as "reducing hash", "reducing world poverty" etc. etc...

LETS TALK ABOUT JITTER!!!! :smoking:

Themis
17-11-2009, 21:34
I will try to find references of how the jitter sounds.
(in my personal experience, it sounds abnormally "warm" in the midrange. You wouldn't expect it, would you ?)

leo
17-11-2009, 21:42
Jitter reducing cables:lol:
You'll make your heads explode guys with all this jitter talk:lolsign:

Mike
17-11-2009, 21:48
Bah!...

I got all excited when I noticed you'd replied. But yer as evasive as all the other buggers! :lol:

leo
17-11-2009, 22:07
Sorry Mike, I've entered into jitter discussions before usually wishing I'd not bothered;)

It would be nice if somebody selling products which are claimed to reduce jitter could comment on it, maybe somebody like Mark from Audiocom?

Themis
17-11-2009, 22:18
Ok then, one article on how does jitter sound.
Disclaimer : this is just an article about an experiment and (although the authors are knowledgable) it should be treated as such : an experiment.

Some extracts:

"How sour, sweet music is if time is broke and proportion kept"
Robert Watson and Richard Kulavik of Burr Brown use this Shakespeare citation in their digital audio design seminar in order to describe the audible effects of jitter.

The experiment
Well, if you want to know the sound of jitter, you have to compare it with "no jitter". Since absolutely no jitter is not possible lets say we compare it with very much less jitter.
The experiment was conducted with a low-quality CDP (which has plenty of jitter) Philips CD723

In order to be sure that we hear jitter effects and not reading errors or interpolations from the CD player we had to monitor the correction flag (cflg) output of the CD-player's decoder chip SAA7376.

For hearing no jitter or very much less jitter we added an Altmann-UPCI (Ultra Precision Clock Injector) that is connected between the digital transmission line from the digital source (f.e. CD player) and the DA converter and strongly attenuates the jitter.

Welcome to Subjectivity
Okay, what comes now is strictly subjective, since the personal perceptions of the people that had the opportunity to audition our experiments.

Anybody can come up an state that it is true or untrue, we cannot care.

Among the listeners were friends / colleges that came by chance and audiophiles with hearing experience.

The tests were always jitter vs. less-jitter or in other words Altmann-UPCI not installed or installed.

We tested with CD (16 bit, 44,1kHz) and DVD (24bit, 96kHz) recordings.

Here the results:

1) It makes a big difference. Everybody (with intact ears) can hear it.

Once heared, one can differentiate within the very first second if the reproduction is jittered or not. It is a totally different sound quality.

2) "Less jitter" sounds better, much better!

Auditioners testified:
o improved ease of listening
o increased clarity
o improved high frequency response
o better instrument separation
o more information
o better timing
o better soundstage
o improved overall audio performance

At this point i would like to refer to the measurements.

If i would urge you to look at the jittered transition (first scopeshot above) and tell me where the exact transition is, you would say to me:

"Are you crazy? The picture is entirely unsharp and it is impossible to say where this damn transition exactly is."
But if you were forced to find out the exact position and you had to use your full concentration, this would surely be a tiring and useless experiment?
Now you know what request from your ear and associated post-processing, if you hear a jittered sound source:
Your ear tries to extract the exact sound and frequency, but it cannot succeed, but it tries to, but it cannot succed, but it tries...
If you then remove (lessen) the jitter something happens that is best described in Ennemoser's book "The Character of Sound":
If the brain, however, receives sound patterns of C37 or similar quality, it has little processing to do and rewards the owner with positive images such as: saturated, full, warm, melting brilliant ..."
If you remove or lessen the jitter to a certain extent, your ear & brain will be relieved from a straining task.

A measurement result of Watson and Kulavik is: "What happens is that the width of a given fundamental will increase in the presence of word-clock jitter. In a jitter free environment a fundamental frequency tone would show up on a spectrum analyzer as an impulse. As jitter is introduced this impulse begins to spread".

This is exactly what you will hear: An instrument's or a singer's voice will spread out. You are not able to define the sound and you have the impression that the single tone is dirty or unclear. If you concentrate on a single tone, it will be as if the tone is rejected by the ear. Just like some kind of recoil. You may identify the frequency of the tone but you are not able to hear whats inside the tone.
Then remove the jitter and the same tone becomes extremely defined, clear and airy. You will hear a wealth of details that was covered before.

It is like the human capability to hear a voice and be able to tell something about how the singer feels. This information or impression lies inside the voice and if you hear any tone, your perception will try to extract all this information.
This information / quality is supplied within a low jitter audio reproduction and can be extracted by the ear very effortlessly.

3) It is an entire new experience to hear a CD with less jitter.

The change in quality is such drastic, that even audiophiles stated, they did not expect to ever get this quality from a CD recording.

4) The same applies for DVD recordings.

Although a DVD 24bit 96kHz recording can give a good sound it will be drastically improved with less jitter.


Full article here : http://www.jitter.de/english/sound.html
.

Mike
17-11-2009, 23:07
Sorry Mike, I've entered into jitter discussions before usually wishing I'd not bothered;)

It would be nice if somebody selling products which are claimed to reduce jitter could comment on it, maybe somebody like Mark from Audiocom?

You're 'among friends' here though! :)

It's my belief that many throw the word about without a care in the world and have little understanding of what it actually is! I'm suspicious of the 'Chinese whispers' syndrome I guess.

Now, I'll readily admit I know something about it within my professional sphere, but at the same time I have little genuine knowledge of it's cause/effect within the audio world. I know that it's 'problems' can be reduced to negligible levels within my own field of expertise, but what about HiFi?... I dunno! :confused:

Just how bad is it, really?

I'm slightly suspicious that it may be a bit of a 'bandwagon' that is often mentioned as being 'a bad thing' and the only answer is to purchase the latest mega bucks 'solution' that so-and-so reference systems has just 'invented' or 'developed' at extraordinary cost. Which, of course, we should feel privileged to pay for!

Is there anything we could do about it oursevles?... Do we need to?

I've a feeling that in the great scheme of things, there are much bigger fish to fry, like the quality of recordings/pressings in the first place, the capabilities of our home systems, what we had for supper, the time of day, etc. etc.

Why the hell is 'jitter' mentioned so much when in practical terms, it would seem, there is bugger all we can do about it?

C'mon folks, is this just another 'problem' that manufacturers need us to spend a gazillion pounds on in order to 'solve'?

Somebody must have an opinion? :scratch:

Get yer barge poll out and 'touch it'! ;)

Marco
17-11-2009, 23:40
Hi Mike,

It's not something I've thought particularly intimately about before, but have certainly used the term (probably incorrectly) to describe an effect I've heard from CDPs or DACs.

Who knows for sure what causes it? It could be down to a number of factors :)

One thing's for sure though - digital sound isn't as 'perfect' as some people claim, or may have claimed, in the past. There's just as much involved (and the process is similarly as laborious), IMO, accurately extracting the music from a CD (with minimal error) as there is doing the same from a record...

Marco.

Mike
17-11-2009, 23:42
Erm... OK! :scratch:

Marco
17-11-2009, 23:53
What's not to understand, like? :)

What I'm saying is that the musical information encoded on a CD has just as 'problematic' a journey to go through to reach our ears, unsullied, through a CDP and DAC, as music has on vinyl via a turntable, arm, cartridge, etc.

There are numerous 'hurdles' said musical information on both formats has to encounter that can (and do) affect its integrity. It's one of the reasons why nine times out of ten these days music servers combined with quality DACs outperform most CDPs, as the number of physical interfaces are reduced which are liable to cause error (and thus loss of data).

Marco.

Mike
17-11-2009, 23:56
Yep... I understand what you're saying just fine.

But what about 'jitter'?... what does it mean to you? :)

Marco
18-11-2009, 00:00
I'll have a think about that and come back to you later - right now I'm off to listen to some choons (and no, not Sting) ;)

Laters,
Marco.

Alex_UK
18-11-2009, 00:41
You put the boom-boom into my heart
You send my soul sky high when your lovin' starts
Jitterbug into my brain
Goes a bang-bang-bang 'til my feet do the same
But something's bugging you
Something ain't right

Marco
18-11-2009, 00:48
No that wasn't one of them! :lol:

I was listening to Portico Quartet's new album 'Isla' and also some Dizzy Gillespie.

Marco.

alb
18-11-2009, 07:55
But what about 'jitter'?... what does it mean to you?

Very little.
Therefore i don't intend to lose sleep over it.
The only time i heard jitter (alledgedly), it manifested itself in the form of a barely noticeable click sound. Much like a light scratch on a record.
Life's too short.......

Dave Cawley
18-11-2009, 09:32
Dimitri is quite right! I posted a link to a White Paper on another thread, no bothered to read it? Or the review that explained so much?

The truth is out there, but you have to go to it, it won't come to you.

Dave

Peter Galbavy
18-11-2009, 11:56
To me perceived jitter is a sign of poor receiver design. Any receiver of asynchronous digital data will have a buffer and the underlying on-the-wire protocol should have a bit-clock recovery method. You receive the data, you identify where the bits start and stop and you fill your buffer, pass out a fixed amount of data to be decoded the continue rceiving the following data.

I simply don't know enough about the on-the-wire format of S/PDIF to comment on why people perceive (or think they perceive) jitter in a datastream of "only" 1.4Mb/sec. We've been dealing with this kind of transmission systems at much higher data rates - and therefore smaller inter-word times - for years. Nowadays 1000TX Ethernet works like a charm and jitter is probably even more critical there.

Anyone care to comment, with real experience, on the buffering qualities of a typical DAC chipset ?

Themis
18-11-2009, 12:25
Peter, there're a couple of fundamental differences between Ethernet and audio data streams :

First, on audio there's no error recovery. If a packet is lost or invalid, it cannot be resend. Ethernet controls lost/invalid packets and requests resending.

Second, the timing of the packets in audio is fundamental : Digital audio is a sum of functions along time. If the timing of an intermediate function definition is not perfect, then the sum is different.

Covenant
18-11-2009, 12:32
I dont profess to know anything about jitter but if you find the use of the term amusing Mike, you will laugh your socks off over on the Squeezebox forums where the term is used like confetti.
The trouble is the designers use the term too.......

Themis
18-11-2009, 12:46
Jitter is unwanted distortion. Like the Harmonic or the Inter-modulation distortions (btw, it has a lot in common with inter-modulation distortion see AES paper here : http://www.nanophon.com/audio/1394_sampling_jitter.pdf page 22 )

It is normal that the designers try to minimize it, exactly in the same way they try to minimize all unwanted distortions, don't you think so ? ;)

Mike
18-11-2009, 16:40
Very little.
Therefore i don't intend to lose sleep over it.
The only time i heard jitter (alledgedly), it manifested itself in the form of a barely noticeable click sound. Much like a light scratch on a record.
Life's too short.......

This is what I'm thinking too. ;)


Dimitri is quite right! I posted a link to a White Paper on another thread, no bothered to read it? Or the review that explained so much?

The truth is out there, but you have to go to it, it won't come to you.

Dave

Eh, what?... must have missed it! Giz a pointer, please. :)

Peter Galbavy
18-11-2009, 16:51
Peter, there're a couple of fundamental differences between Ethernet and audio data streams :

First, on audio there's no error recovery. If a packet is lost or invalid, it cannot be resend. Ethernet controls lost/invalid packets and requests resending.


This is not quite right. Ethernet (in the form of the primary IEEE 802.3 standards) have no error recovery. There is error detection in the form of CRC checks.


Second, the timing of the packets in audio is fundamental : Digital audio is a sum of functions along time. If the timing of an intermediate function definition is not perfect, then the sum is different.

Erm, pardon ? Digitial audio, in terms of LPCM at least, is a pretty simply linearly sampled bitstream - again, while I don't know the S/PDIF packet layout - there must be a start-of-frame, end-of-frame, some sort of bit-boundary encoding etc. else how do you every know where a sample starts and ends ?

Peter Galbavy
18-11-2009, 17:18
Right, been trying to read up a bit about the S/PDIF on-the-wire protocols.

While it *is* wackypedia, there are some good references here:

http://en.wikipedia.org/wiki/S/PDIF
http://en.wikipedia.org/wiki/AES/EBU

and most interestingly here

http://en.wikipedia.org/wiki/Biphase_mark_code

The last article shows how, for both coax and toslink, the clock is encoded in the data stream. The comment in the AES/EBU article is interesting: "No attempt was made to use a carrier able to support both rates; instead, AES/EBU allows the data to be run at any rate, and recovers the clock rate by encoding the data using biphase mark code (BMC)."

Given the structure of the data blocks I cannot see how you can receive, decode and convert samples without buffering. Buffering, if then specified correctly, should in any good design be able to eliminate jitter up to some specified tollerence. Given that there are, again according to the AES/EBU article, 250 "data blocks" per second for 48KHz sampling, it should be reasonable to buffer some number of these blocks in circular buffers and decode based on that.

Again, has anyone got any real world DAC chipset experience to expand on what a typical design actually does ?

Themis
18-11-2009, 17:27
This is not quite right. Ethernet (in the form of the primary IEEE 802.3 standards) have no error recovery. There is error detection in the form of CRC checks.
IEEE standard says that MAC layers do not provide error recovery.
Instead the error recovery is provided by MAC clients or higher (sub)layers.
You understand that in the computer world error recovery is critical. All comunications provide error recovery when applicable (when the communication path is not destroyed).
The CRC checks provide error detection. But an error detection without error recovery, just drops the invalid paquets... That's what happens on audio : if a paquet is invalid -say- from the CDP to the DAC, the DAC can detect the invalid paquet, but it cannot ask the CDP to re-send it. The paquet is discarded.


Erm, pardon ? Digitial audio, in terms of LPCM at least, is a pretty simply linearly sampled bitstream - again, while I don't know the S/PDIF packet layout - there must be a start-of-frame, end-of-frame, some sort of bit-boundary encoding etc. else how do you every know where a sample starts and ends ?
I'll try to be simple:
To give you an example, the value of each paquet will produce a "sound". The sum of the consecutive sounds, will produce what you hear.
Ideally, each individual sound should be played in a particular moment in time : this is regulated by a clock. If the clock has a variable error, for instance, then the overall sound is not what it should be. It is, thus, distorted.
You can find more here : Dan Lavry's explanations (http://go.head-fi.org/?id=475X763&url=http%3A%2F%2Fwww.lavryengineering.com%2Fwhite_ papers%2Fjitter.pdf)

Peter Galbavy
18-11-2009, 17:34
The CRC checks provide error detection. But an error detection without error recovery, just drops the invalid paquets... That's what happens on audio : if a paquet is invalid -say- from the CDP to the DAC, the DAC can detect the invalid paquet, but it cannot ask the CDP to re-send it. The paquet is discarded.


Yes, and it's the upper layers that provide error recovery. TCP being the most commonly known. The PHY/MAC layer of 802.3 does none of that. Just like audio :)


I'll try to be simple:
To give you an example, the value of each paquet will produce a "sound". The sum of the consecutive sounds, will produce what you hear.
Ideally, each individual sound should be played in a particular moment in time : this is regulated by a clock. If the clock has a variable error, for instance, then the overall sound is not what it should be. It is, thus, distorted.
You can find more here : Dan Lavry's explanations (http://go.head-fi.org/?id=475X763&url=http%3A%2F%2Fwww.lavryengineering.com%2Fwhite_ papers%2Fjitter.pdf)

But hang on there... People seem to be talking about jitter as a function of the cables and sources etc. in the form of inter-symbol timing issues. If the physical layer provide for clock recovery - and again, the design of the receiver is "good" - then the influence of the physical carrier on the reconstructed bitstream is *zero*.

If we are talking then about jitter in the form of timing errors between samples, either inter-channel or intra-channel, then that's the problem of the decoder and not the transmission medium.

If we are talking about errors and the async, non-recoverable nature of digital audio then that is not jitter and the loss of samples ahout be trivially detectable by the receiver and an indication can be provided (in the form of am error LED etc.) to the human interacting with the system.

Themis
18-11-2009, 17:47
Yes, and it's the upper layers that provide error recovery. TCP being the most commonly known. The PHY/MAC layer of 802.3 does none of that. Just like audio :)
How's that : "just like audio" ?
Can you please explain to me where did you see Ethernet communications without upper layers ? :lol:
And can you please explain where are the "upper layers" of S/PDIF transmission ?



But hang on there... People seem to be talking about jitter as a function of the cables and sources etc. in the form of inter-symbol timing issues. If the physical layer provide for clock recovery - and again, the design of the receiver is "good" - then the influence of the physical carrier on the reconstructed bitstream is *zero*
Your phrase has two "if"s. How about reality ? ;)

Alex Nikitin
18-11-2009, 17:50
My 2 cents ;) .

Few words about jitter.

I can define jitter as a variance of time-related parameters of a signal in relation to the ideal timing. It can happen in many places and the jitter may have different names according to the application - it is essentially the same thing as the phase noise in RF or the W&F in an analogue recording/reproduction. In digital signal applications there are two distinct areas where jitter matters - and these very often mixed up and that creates a lot of misunderstandings. Those two areas are - the data transmission and AD and DA conversions. In the first case an excessive jitter can lead to a data loss and there is a clear criteria - the level of errors in the datastream, usually it has to be kept to a minimum. The jitter as applied to the audio field is usually related to the second area - analogue to digital (AD) and digital to analogue (DA) conversions.

In brief - AD conversion requires to measure precise samples of the value of an analogue input signal (voltage, current etc.) in precise moments in time. Important to remember that BOTH these requirements need to be satisfied for a proper conversion. First - the precision of the value - depends on the quality of the quantizer, its resolution, i.e. number of bits and how precisely it measures the value. Second, however, depends on the precision in timing, or JITTER. In AD conversion it is usually called the "aperture jitter". It is always present in any digital recording and in many ways it may ultimately limit the quality of the recording. We, as users of digital audio, can not do much about this side of the story. However, in order to hear the sound, we have at a certain point to convert the data back to an analogue signal. And again, two main kinds of error could happen at this stage, during DA conversion - level errors, due to the imperfections in the level for each point and the timing errors, due to the jitter in the master clock, used for the DA conversion. It is useful to know, that either of these errors does effectively reduce the resolution of the DA converter, leading to the loss of the information, contained in the digital audio data.

Now the last part. Unfortunately, in the SPDIF interface the master clock for DA conversion is transmitted together with the signal and is recovered by the receiver. In this method of transmission the master clock is inevitably "polluted" by the jitter, added both from the data (data-induced jitter) and by additional timing errors of the interface (reflections, noise etc.) . The receiver tries to clean up the clock by filtering it, however it is not an easy task. As a result, our music gets polluted by additional "jitter-related" distortion. And these do depend on the cables, RF interference, grounding, power supply arrangements etc. etc.

However - I should stress again, as long as the data is transmitted without errors, the jitter matters only in the processes of DA and AD conversions.

Alex

Mike
18-11-2009, 17:59
Ah, at last! :)

Now there's something for me to read and have a good think about!

Cheers...

Mike
18-11-2009, 18:12
I particularly like this bit...


In brief - AD conversion requires to measure precise samples of the value of an analogue input signal (voltage, current etc.) in precise moments in time. Important to remember that BOTH these requirements need to be satisfied for a proper conversion. First - the precision of the value - depends on the quality of the quantizer, its resolution, i.e. number of bits and how precisely it measures the value. Second, however, depends on the precision in timing, or JITTER. In AD conversion it is usually called the "aperture jitter". It is always present in any digital recording and in many ways it may ultimately limit the quality of the recording. We, as users of digital audio, can not do much about this side of the story. However, in order to hear the sound, we have at a certain point to convert the data back to an analogue signal. And again, two main kinds of error could happen at this stage, during DA conversion - level errors, due to the imperfections in the level for each point and the timing errors, due to the jitter in the master clock, used for the DA conversion. It is useful to know, that either of these errors does effectively reduce the resolution of the DA converter, leading to the loss of the information, contained in the digital audio data.

Takes me right back to 'PCM' which is something I understand well.

I can't help thinking, though, that S/PDIF could have been better conceived. Or better still, a different 'standard' adopted in the first place... :scratch:

Dave Cawley
18-11-2009, 19:19
Wasn't CD designed to be an easy thing? Not a high quality thing?

Does anyone remember Tomorrows World drilling holes in a CD and it still worked? Do you think that was fake?

Regards

Dave

StanleyB
18-11-2009, 19:42
Does anyone remember Tomorrows World drilling holes in a CD and it still worked? Do you think that was fake?

I still use the Philips test disc that has those holes in varying sizes in it. The set cost a fortune to buy, and I don't know anyone except for me who has a set of those test discs. It is very handy in sorting out excellent to useless CD players.

Dave Cawley
18-11-2009, 22:58
Hi Stan

Wow! and I thought I was the only one left who saw Tomorrows World drilling holes in a CD and it still working. Red book?

I must try that on the Andy Williams CD I just won on eBay?

Dave

StanleyB
19-11-2009, 07:58
That edition of the program is what caused me to switch from radio & TV engineering, to audio engineering:).
On the subject of jitter: thee are two important types of jitter in a CD player. One is focus jitter, and originates at the laser pickup end. The other is frequency jitter, and can be associated with the motors or their drivers.

Alex Nikitin
19-11-2009, 09:07
On the subject of jitter: thee are two important types of jitter in a CD player. One is focus jitter, and originates at the laser pickup end. The other is frequency jitter, and can be associated with the motors or their drivers.

I would not call either of these jitter, as we do not consider a focus error or a servo current as a signal - at best as sources of interference (from the digital data point of view). It is possible (and usually is the case) that this unwanted interference through the power supply etc. is responsible for some part of the jitter in the clock and data lines, but that is all to it.

Alex

Peter Galbavy
19-11-2009, 09:40
How's that : "just like audio" ?
Can you please explain to me where did you see Ethernet communications without upper layers ? :lol:
And can you please explain where are the "upper layers" of S/PDIF transmission ?


I meant no error recovery, just like S/PDIF digital audio. And Ethernet without uppoer layers that do themselves not do error recovery is very common.



Your phrase has two "if"s. How about reality ? ;)

I'm still waiting for someone with direct, real, experience of DAC chipsets to explain...

All I am seeing is regurgitated, reworded stuff about how clock recovery affects the D/A process - there is some assumption that the S/PDIF bitstream is just a continuous set of samples with no framing structure and other higher level data. I can understand that in a cheap, poorly designed D/A process the master clock is recoveryed from the datastream and that in turn is divided down and used to derive the sample-conversion interval clock, but surley in anything except the worst implementations there is a real reference clock (44.1 or 48 or 96KHz) that is used to drive that - the bitstream being recovered in block format and decoded with *enough* of a buffer to allow for signal jitter to be ignored in the actuallt D/A process.

Looking at the block structure of S/PDIF data how can you convert any samples without converting a blocks worth (1/250th second at 48KHz) ?

Themis
19-11-2009, 09:53
Peter, as you seem to know very well Ethernet, and as I disagree with your "very common" part, could you please provide a concrete implementation of a protocol using Ethernet without error recovery ?

As for jitter, I'm sorry to say, but if you looked at the links I provided, you would have noticed they were all written by people who actually design A/D/A implementations. Let alone the AES papers.
Now, if you think you can prove using simple, sheer logic that jitter just doesn't exist in a "well designed D/A process", well, you can too. But in this case I guess you'll have to live with the fact that such a "well designed D/A process" just doesn't exist. Simply because output jitter of all D/A processors is measurable. :)

Alex Nikitin
19-11-2009, 10:06
I can understand that in a cheap, poorly designed D/A process the master clock is recoveryed from the datastream and that in turn is divided down and used to derive the sample-conversion interval clock, but surley in anything except the worst implementations there is a real reference clock (44.1 or 48 or 96KHz) that is used to drive that - the bitstream being recovered in block format and decoded with *enough* of a buffer to allow for signal jitter to be ignored in the actuallt D/A process.

Unfortunately, all SPDIF connections do not use an independent clock. SPDIF is a synchronous interface and the conversion clock is always recovered from the datastreem by means of a PLL. And buffering of the data does not help - most modern DAC chips do it internally anyway. Problem is usually not with the data jitter but with the clock jitter.

Alex

P.S. - even in a CD player, where a single good crystal controlled master clock is available , the power supply interferences and EM radiation create a problem with jitter. And the quality of the clock is of utmost importance - there is a surprising difference in the sound quality between a cheap crystal oscillator and an elaborate master clock with 20-40 dB lower phase noise (i.e. jitter) at LF and much better PSRR.

StanleyB
19-11-2009, 10:15
I would not call either of these jitter, as we do not consider a focus error or a servo current as a signal - at best as sources of interference (from the digital data point of view).
Call it what you want, but it is jitter:). Unlike you, I do have repair, design, and manufacturing experience of CD players and laser pickups;). At one stage the company I worked for was the largest supplier of replacement CD pickup in Europe, and I spent many sleepless nights trying to trace production line faults from time to time. So any suggestions that it is interference would not furnish you with a job in CD pickup manufacturing.

Dave Cawley
19-11-2009, 10:16
Which is why this review was so important? http://www.soundhifi.com/images/Hifi%20World%20Grimm%20Clock.pdf

Dave

nat8808
19-11-2009, 10:23
I would not call either of these jitter, as we do not consider a focus error or a servo current as a signal - at best as sources of interference (from the digital data point of view). It is possible (and usually is the case) that this unwanted interference through the power supply etc. is responsible for some part of the jitter in the clock and data lines, but that is all to it.

Alex

Could these both be causes of the jitter you talked of earlier?

Of course, when talking about CDs or DVDs, there is the data reading process from the disc between the A/D and D/A conversion which shouldn't be forgotten.

In the data reading process, can the same measurement errors as you mentioned in the A/D process again be encountered or created by poor pick-up of the data?

StanleyB
19-11-2009, 10:30
Unfortunately too many people jump on the clock as the main culprit. Texas Instruments has a very good paper on jitter errors resulting from the charge delay in the sequential stepped response from a digital to analogue conversion process. This error can be reduced by increasing the sampling frequency.

But honestly, anyone who can hear a missing bit or frequency shift at 44.1KHz must be inhuman.

Alex Nikitin
19-11-2009, 10:32
Unlike you, I do have repair, design, and manufacturing experience of CD players and laser pickups;). At one stage the company I worked for was the largest supplier of replacement CD pickup in Europe, and I spent many sleepless nights trying to trace production line faults from time to time. So any suggestions that it is interference would not furnish you with a job in CD pickup manufacturing.

Stanley, please do not make assumptions if you do not know all the facts :smoking: . I did in the past designed and manufactured a number of good CD players and DACs, dealt with many different CD pickups and did even design processing circuitry, including the PCB layout for the output of a laser pickup. Yes, from the point of view of that signal processing there is jitter (and a lot of it) from the pickup. However - and that is crucial - all of this jitter is removed happily by buffering of the data in the DSP. And this buffer is present in every CD player. In essence, if the digital PCM data is recovered from the CD media correctly, we do not care even a slightest bit about the jitter from the pickup, full stop. The only way this jitter can influence the output is by EM and power supply interference, and a good common sense design practice can help you here ;) .

Alex

Mr. C
19-11-2009, 11:52
Unfortunately, all SPDIF connections do not use an independent clock. SPDIF is a synchronous interface and the conversion clock is always recovered from the datastreem by means of a PLL. And buffering of the data does not help - most modern DAC chips do it internally anyway. Problem is usually not with the data jitter but with the clock jitter.

Alex

P.S. - even in a CD player, where a single good crystal controlled master clock is available , the power supply interferences and EM radiation create a problem with jitter. And the quality of the clock is of utmost importance - there is a surprising difference in the sound quality between a cheap crystal oscillator and an elaborate master clock with 20-40 dB lower phase noise (i.e. jitter) at LF and much better PSRR.

Good morning Alex,

Genuine, honest and refreshing good reply, it has always been our case when designing any digital signal processing that RFI and EMI considerations are always taken serious sand incorporated in the finished article.
We have also found that ultra quiet, very close tolerance voltages and discrete dedicated individual power supplies to the clock circuit/ dsp and processing arrays/ and digital to analogue conversion sections pay dividends even more so that using the very latest uber clocks. (1.9 to 3.3Vrms)
Though as with all quality designs, the implementation is the key to the final performance.

Tony

nat8808
19-11-2009, 11:57
I will try to find references of how the jitter sounds.
(in my personal experience, it sounds abnormally "warm" in the midrange. You wouldn't expect it, would you ?)

The guy who does those Lampizator valve mods has an interesting page regarding the CEC belt driven transport that was reviewed as being very warm and musical, especially in the mid-range..

Read his deconstruction of it here (http://www.lampizator.eu/LAMPIZATOR/REFERENCES/CEC/CEC%20TL-1X.html)

In brief (I know how people hate to click on the links) he found that the s/pdif output trace (for a single frequency sine wave being played I guess) was being deliberately doctored, shaped so as to induce jitter and so sound warm!

Alex Nikitin
19-11-2009, 12:24
The guy who does those Lampizator valve mods has an interesting page regarding the CEC belt driven transport that was reviewed as being very warm and musical, especially in the mid-range..

Read his deconstruction of it here (http://www.lampizator.eu/LAMPIZATOR/REFERENCES/CEC/CEC%20TL-1X.html)

In brief (I know how people hate to click on the links) he found that the s/pdif output trace (for a single frequency sine wave being played I guess) was being deliberately doctored, shaped so as to induce jitter and so sound warm!

I did click on the link and even read the page. That guy doesn't know what he is talking about :( (put it mildly).

Alex

NRG
19-11-2009, 12:24
Peter, as you seem to know very well Ethernet, and as I disagree with your "very common" part, could you please provide a concrete implementation of a protocol using Ethernet without error recovery ?


UDP? :confused:

Themis
19-11-2009, 14:12
UDP? :confused:
Good. Now let's see the differences between TCP and UDP : Which one would we use if reliability was a concern ?

Then, let's go back to audio: as S/PDIF has no reliability, which protocol could we use if reliability was a concern ?

Alex Nikitin
19-11-2009, 14:30
Good. Now let's see the differences between TCP and UDP : Which one would we use if reliability was a concern ?

Then, let's go back to audio: as S/PDIF has no reliability, which protocol could we use if reliability was a concern ?

Dimitri,

the SPDIF is more than reliable enough for audio purposes as a data transmission protocol. Generally, if there is no major fault and the receiver can synchronise the clock the data usually transferred without any errors whatsoever. If there is a serious problem, the receiver will flag the errors or will just not be able to recover the clock and the output will be muted or heavily distorted. Problem is not with the data. SPDIF transfers both components for the DA conversion - data and timing. It is the timing part that always suffers - and the data part is almost always does not suffer.

Alex

Themis
19-11-2009, 15:52
Alex, I've no doubt that data suffers very little (if at all).
What I cannot understand, is why timing is not explicitly transported with the same reliability concerns.
It seems to me (but I may be mistaken) that there could be better ways for transferring the clock than the way it's done actually.
I would even say that ideally (at least that's my way of seeing things) clock should be even explicitly stored from the A/D process along with the data : this way, choosing adequate transport layer, our only concern would be to faithfully reproduce the initial (A/D) timing errors. Is this correct ?

Alex Nikitin
19-11-2009, 16:43
Alex, I've no doubt that data suffers very little (if at all).
What I cannot understand, is why timing is not explicitly transported with the same reliability concerns.
It seems to me (but I may be mistaken) that there could be better ways for transferring the clock than the way it's done actually.
I would even say that ideally (at least that's my way of seeing things) clock should be even explicitly stored from the A/D process along with the data : this way, choosing adequate transport layer, our only concern would be to faithfully reproduce the initial (A/D) timing errors. Is this correct ?

Hi Dimitri,

The timing part of the AD and DA conversion is absolute - that means that it is derived from a primary reference - the Time - as frequency. It can not be "stored" in any other way as just a number - i.e. 44100 Hz for CD. The stored data has no "timing" part except that number. Data sampled at equal (theoretically) intervals, and has to be restored at same intervals. Errors in that timing is the jitter of the conversion process - both for AD and DA conversions. We can not in practice trace and "map" timing errors of the AD converter. In case of the DA conversion we can control timing by using better DAC chips and better clocks, better power supply and layout, better grounding and screening etc. Better interface too. One of good options is to supply the transport with a separate clock line from a low-jitter clock inside the DAC and just reclock the incoming data to the local clock. That would completely remove the interface influence on the jitter as well as the local influence on the clock from the transport motors and servos. Unfortunately, to my knowledge there are very few transport - DAC combinations made like this.

Alex

Alex_UK
19-11-2009, 22:21
Does anyone remember Tomorrows World drilling holes in a CD and it still worked? Do you think that was fake?

Oh I remember - Thursday nights are always my favourite nights, I think it stems from my Mum & sister going to lace making classes, and me and Dad would watch Tomorrow's World, Blake's 7 and Blankety Blank and have a portion of illicit chips!

NRG
20-11-2009, 07:58
I remember watching an OU program on the Beeb back in the 80's showing a similar demonstration. Clearly recall long slots machined into the CD...I was very impressed!

sastusbulbas
22-11-2009, 20:42
Holes or slots made in a CD? Is this not more to do with error correction than jitter?

Even a system with copeous amounts of jitter will still play.

Anyway, I think jitter is real and can require addressing, though the results are not always the same, nor is it required for everything. Benchmark and the rest addressed this well enough for it not to cause to big a problem. Sadly many of us still enjoy lagacy hardware which does show up differences between good and bad digital sources.

Small mid 90's cigarette packet jitter busters are not the sollution, as they only address a narrow band of jitter at specific frequencies.

Primalsea
27-11-2009, 09:15
The Stereophile review of the Chord DAC64 is quite informative in regards to jitter:
http://www.stereophile.com/digitalprocessors/624/index.html

I always thought that as long as you had a very high accuracy clock bang next to the DAC jitter would be eliminated. The idea being that it doesn't matter if the various bits arrive late (or early) at the dac so to speak as long as the entire 16 bit word was clocked out of the dac as an analogue signal on time the analogue signal would suffer no jitter derived inaccuracies.

However after reading the review I realised that its not as simple as this.