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

[alb]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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