A question about jitter

[maarek99]

You guys are talking an awful lot about jitter here.

If I just send a pcm signal then jitter can change it? How lame is this digital out thing if this is true? If any bits change during the transport then its not really digital I would say. We can send miles and miles of correct bits using extremely low quality cables on the internet or in a network but we can't send an audio signal a couple of meters without the bits changing?

If I send a DD-encoded signal through SPDIF there CANNOT be an audible difference between different wires or between transports because the signal is DD encoded. If the bits change the audio will just stop. But this seems to be different when a pcm signal is being sent, why?

 

[Wodgy]

There are two separate things being transmitted by S/PDIF (and any digital signal for that matter): 1) the data itself, and 2) the timing.

Any competent S/PDIF digital transmitter and receiver will never make errors on the data. Bits are bits. You're right about that. (That's not to say that there aren't sound cards that fail even this simple test. We can blame poor engineering, kMixer, and a variety of other issues for that. But this is largely a separate issue. A good sound card properly set up will output the same digital data as a quality CD player.)

Timing (jitter) is another issue. Most DACs derive their clock timing from the S/PDIF signal transitions. This means an unstable clock on the incoming data gets fed through to the converter itself. This causes the distortion products in the resultant audio signal to increase. Such distortion products are called "jitter induced sidebands" and they are measurable. Most frequently they're plotted on an "eye" plot. Stereophile now usually publishes such plots as part of its measurements of reviewed gear, so you can judge the jitter sensitivity of a given DAC. The real question is: this distortion may be measurable, but is it audible? Recent papers at the AES have shown that with modern DAC designs, as little of 20ps of jitter is indeed humanly audible.

The simple answer, obviously, is just for the DAC to reclock its incoming data. Indeed, this is the main reason asynchronous reclocking ICs have become popular (for instance, they're used in the Benchmark DAC1 and Bel Canto DAC2). DACs that do this are not sensitive to jitter.

Incidentally, clock jitter is also one of the reasons why so many modern low end DVD players sound so terrible with CD playback, worse in fact than many low end CD players from ten years ago, even though the DAC chips themselves have improved. By the nature of the beast, DVD players typically use low quality PLLs to generate a clock for their PCM DACs.

 

[gaboo]

Quote:

Originally Posted by Wodgy The simple answer, obviously, is just for the DAC to reclock its incoming data. Indeed, this is the main reason asynchronous reclocking ICs have become popular (for instance, they're used in the Benchmark DAC1 and Bel Canto DAC2). DACs that do this are not sensitive to jitter.

This is not exactly true. You cannot eliminate the influence of line/sender jitter this way. You can only diminish it. ASRC does not eliminate jitter. In fact it encodes jitter input into output data. Once this happens, you cannot get rid of it anymore.

There are much better solutions:

• Send data in bursts at a fast rate, but equaling the receiver clock on average. This requires an isochronous protocol. USB Audio and Firewire audio (IEC 61883-6) are exactly this. Heck, you can even send multiple streams this way; mLAN does just that.
• Use the clock of the dac as clock for the sender. The simplest solution is a clock line. This called "word clock", and is sent on separate line. Sony SDIF-2/3 and Phillips I2S integrate the word clock in the protocol. The disadvantage of this is that you need to send a high speed clock, which has its own problems. Lin has a more sophisticated solution, a distributed PLL, where the DAC controls the sender's clock through a simple voltage (but this is an analog solution!).

I have some links, but I'm too lazy to put them now, I'll edit the post later...

Quick poll: is a jitter FAQ necessary on this board? I have quite a bit of material on this...

 

[Wodgy]

Quote:

Originally Posted by gaboo This is not exactly true. You cannot eliminate the influence of line/sender jitter this way. You can only diminish it.

Yes, I know, but I didn't want to confuse the guy asking the question. There's an excellent old thread about this (and ASRCs in general) over at DIYaudio by the lead engineer for one of Cirrus/Crystal's ASRCs. ASRCs, like everything else, can only be a jitter filter (engineers love to think of everything as a filter) but as far as filters go they're quite effective if implemented correctly. (Yes, I also know that the new Burr-Brown ASRC has some serious implementation issues that make it a poor jitter filter, despite the datasheet claims.)

BTW, your first proposed solution, isochronous protocols, does not solve the jitter problem any more than a standard S/PDIF receiver does. With an isochronous protocol you need a rate estimator, hence a PLL. Modern S/PDIF receivers use similar rate estimators and PLLs. The actual clocking is no longer extracted from the actual S/PDIF transitions -- that's obviously a very high jitter approach.

 

[gaboo]

Quote:

Originally Posted by Wodgy Yes, I know, but I didn't want to confuse the guy asking the question. There's an excellent old thread about this (and ASRCs in general) over at DIYaudio by the lead engineer for one of Cirrus/Crystal's ASRCs. ASRCs, like everything else, can only be a jitter filter (engineers love to think of everything as a filter) but as far as filters go they're quite effective if implemented correctly. (Yes, I also know that the new Burr-Brown ASRC has some serious implementation issues that make it a poor jitter filter, despite the datasheet claims.)

Been there.

Quote:

Originally Posted by Wodgy BTW, your first proposed solution, isochronous protocols, does not solve the jitter problem any more than a standard S/PDIF receiver does. With an isochronous protocol you need a rate estimator, hence a PLL. Modern S/PDIF receivers use similar rate estimators and PLLs. The actual clocking is no longer extracted from the actual S/PDIF transitions -- that's obviously a very high jitter approach.

Yes, you are right. First solution is wrong. IEC 61883-6 has significant jitter, and I assume USB Audio falls into the same trap (please correct me if I'm wrong).

But, it can be easily fixed by sending data at a slightly higher rate and using flow control. Heck, you know this better than I do.

Btw, if the bus speed is high enough, you can even get away with a burst asynchronous protocol with flow control.

EDIT: I was living under the impression that IEC 61883-6 has flow control. But it doesn't. Bummer.

 

[gaboo]

You can buffer at sample rate as well, e.g. Chord DAC64. But you have to put up with the inherent delay and weirdness.

 

[macbrush]

Airport Express have archieve no jittering transmittion. But then... yeah, I know its over a computer network and its different. Well... if hi-fi manufacturers are willing to throw in some cheap computer network components into their products, we can all forget about all cabling troubles, can't we? Well... at least for the digital side anyway.

Forcing this to be a realtime applications doesn't make any sense to me anyway. It just give those cable manufacturers a big chance to suck blood from us.

 

[gaboo]

Quote:

Originally Posted by macbrush Airport Express have archieve no jittering transmittion. But then... yeah, I know its over a computer network and its different. Well... if hi-fi manufacturers are willing to throw in some cheap computer network components into their products, we can all forget about all cabling troubles, can't we? Well... at least for the digital side anyway. Forcing this to be a realtime applications doesn't make any sense to me anyway. It just give those cable manufacturers a big chance to suck blood from us.

Yeah, it's quite shocking that no standard jitterless protocol exists for this.

 

[thomaspf]

Audio receivers connected by Ethernet are by the pure nature of how Ethernet works connected asynchronously. Apple did not invent anything new here.

USB audio does support asynchronous sinks with flow control as well for many many years.

Once you keep the audio data in the asynchronous domain with flow control you just need to worry about keeping you buffer right before the DAC filled with data and you should be fine.

The Chord DAC64 mentioned above has a deep buffering mode with 4s buffers which is also an asynchronous design but with a jitter buffer instead of flow control. The local clock at the DAC is fixed at that setting and you hope that the drifft between the S/PDIF input signal and the local clock does not exceed 4s for the time you continuously play.

Cheers

Thomas

 

[gaboo]

Quote:

Originally Posted by thomaspf Audio receivers connected by Ethernet are by the pure nature of how Ethernet works connected asynchronously. Apple did not invent anything new here.

I understand this, but how many dacs have Ethernet ports? An where's the audio-over-Ethernet standard defined?

Quote:

USB audio does support asynchronous sinks with flow control as well for many many years.

Thanks! This was what I was looking for. Details on page 19 in the spec.
Didn't expect to ever say this, but USB spanks firewire in this regard. Of course it's possible to do it with 1394, but the lack of a standard protocol just plain sucks. I suspect this due to the fact that firewire audio was intended to be broadcast protocol (the firewire isochronous frames are anyway).

There are still a couple of problems: (1) USB Audio does allow for isochronous endpoints as well. I have yet to see an audio USB device that clearly states that it's an async endpoint. (2) AFAICT the synchronization mechanism for async sinks is left to the implementer; the audio spec just points to the general USB spec data flow chapter without mandating some mechanism.

I've also discovered: http://usb-audio.com/. It seems a widely accepted USB ASIO driver that has been licensed by many manufacturers. So it is a de facto standard besides MS WDM driver. Of course it doesn't say anything about issue (1) above...

Quote:

Once you keep the audio data in the asynchronous domain with flow control you just need to worry about keeping you buffer right before the DAC filled with data and you should be fine. The Chord DAC64 mentioned above has a deep buffering mode with 4s buffers which is also an asynchronous design but with a jitter buffer instead of flow control. The local clock at the DAC is fixed at that setting and you hope that the drifft between the S/PDIF input signal and the local clock does not exceed 4s for the time you continuously play. Cheers Thomas

My point with DAC64 is that for async protocols you need (much) higher burst rate than the signal rate. Otherwise you run exactly into the problem you mention: clock drift.

 

[thomaspf]

RFC 1889 describes the RTP protocol which has been around for 10 years or so. There are encapsulations for any imaginable format under the sun and mapping to carry RTP over TCP.

To my knowledge Turtle Beach was one of the first companies to come out with a viable consumer device in the shape of the Audiotron. The problem is that the quality of all these solution is targeted towards mid-fi at best.

For some reason beyond my imagination there seems to be a large numbr of boutique high-end vendors building quality DACs with AES/coax/Toslink connectivity but no one has picked up on a really high end Ethernet DAC. This is bound to happen ....

Cheers

Thomas

 

[gaboo]

Quote:

Originally Posted by thomaspf RFC 1889 describes the RTP protocol which has been around for 10 years or so. There are encapsulations for any imaginable format under the sun and mapping to carry RTP over TCP.

And how many dacs implement TCP? I mean a protocol simple enough for hi-fi (dyi) electronics.

Now if you use this 160-pin 50Mhz monster for interface, then you could use almost anything for protocol. And you should be able to leverage on current USB audio async host drivers. Heck, you can attach a disk to it and not need a source, but UI would be a problem. There are ARM7 cores with built in nics as well, but I don't know of any with nics and i2s...

Quote:

To my knowledge Turtle Beach was one of the first companies to come out with a viable consumer device in the shape of the Audiotron. The problem is that the quality of all these solution is targeted towards mid-fi at best.

Agreed. This is not a big deal as long the internal interface to the DAC is well known like i2s, and the board isn't too fancy: > 2 layers or BGA chips. Should be hackable/moddable.

Also see my post about hifidelio. At least it has a linear psu. Still in midfi though (based on the price).

Quote:

For some reason beyond my imagination there seems to be a large numbr of boutique high-end vendors building quality DACs with AES/coax/Toslink connectivity but no one has picked up on a really high end Ethernet DAC. This is bound to happen .... Cheers Thomas

My point exactly. All this high-end stuff with a crappy input interface...

 

[Glassman]

good solution using existing S/PDIF standard is buffering say half a second and running VCXO oscillator controlled by very long digital PLL, half a second is more than enough to keep track with incomming clock and on the other hand not so disturbing delay..

as for perfect interface, yes, D/A must have control over incomming data stream, this is doable with USB, having master clock in the DAC box with some buffer, asking the computer for data when needed.. not like stupid isochronous mode.. this however require writing your own drivers and also software for the USB device itself..

 

[clarke68]

Quote:

Originally Posted by thomaspf For some reason beyond my imagination there seems to be a large numbr of boutique high-end vendors building quality DACs with AES/coax/Toslink connectivity...

I haven't been deeply into digital audio for very long, but seems like for a few years there a lot of high-end audio companies were "solving" the jitter issue by moving away from outboard DACs, and more towards single-box solutions.

Quote:

Originally Posted by thomaspf but no one has picked up on a really high end Ethernet DAC. This is bound to happen...

That's a really good point, and a good suggestion (high-end audio companies, are you listening?). I think it is bound to happen as more and more people turn to computer-as-source.

 

[gaboo]

Since the USB Audio spec is clear as mud on this, I took at peek at the source. The linux usb adio driver that is. The good news: async audio is supported. The bad news: there seems to be exactly one(!) device that uses that: Dallas USB DAC. Their web site doesn't have any data sheets...

From the driver code, I can tell that the USB device is the one to decide whether it wants an sync or async pipe. So there could be plenty more devices that are async.

Call for help: those that know how to run an USB sniffer, please sniff your favorite USB sound card and post here whether it is sync or async.

Glassman: it seems that we won't need any special drivers on the host to handle async USB audio, the default one seem to be fine. At least on linux.