Jitter... what's that all about then?

[Alex Nikitin]

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

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]

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?

[Themis]

UDP?

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]

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]

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]

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]

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]

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]

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]

The Stereophile review of the Chord DAC64 is quite informative in regards to jitter:
http://www.stereophile.com/digitalpr...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.