[JDUBS]

Hey Everyone

I've heard that USB inherently has very low jitter:

http://www.wavelengthaudio.com/Cosecant.html

I've also heard that it introduces all sorts of jitter. What's the truth here? I really want to directly couple my Sonica to my Panasonic XR-50 but if it would be better for me to use a E-MU 1212 as a transport, I'll go that route.

Just curious if anyone's done any measurements?

Thanks!

-Jim

 

[thomaspf]

USB audio is packetized and asynchronous. The type of jitter I assume you are worried about is the jitter at the word clock of your DAC when this clock is directly derived from the S/PDIF digital input?

The level of jitter you will see there depends only on the stability of the oscillator circuit for the digital output of the Sonica. Once the audio packets have arrived at the Sonica and are buffered within that device they have forgotten that they ever travelled over USB

Cheers

Thomas

 

[Glassman]

well, they haven't forget anything.. Sonica derives the word clock from USB clock using PLL.. the frequency of PLL is then updated ever once..

 

[Wodgy]

Quote:

Originally Posted by thomaspf USB audio is packetized and asynchronous. ... Once the audio packets have arrived at the Sonica and are buffered within that device they have forgotten that they ever travelled over USB

Not quite. USB audio is isochronous and, even though the data is buffered, USB audio devices need a PLL to estimate the master clock rate used by the transmitter (the computer). A buffer alone is not enough -- if you work through the isochronous protocol on paper, you'll realize that without an accurate estimate of the master clock rate, the buffer will be always either empty or always overfilling.

Thus, ultimately, USB audio is not substantially different in terms of jitter than regular old S/PDIF. USB audio receivers from Texas Instruments/Burr-Brown even use the same algorithm (SpAct) for reconstructing the master clock than their S/PDIF audio receivers (e.g. DIR1701).

The Wavelength Audio web page mentioned by the original poster is complete bull -- it's clear to me that the Wavelength Audio guy has no idea what is going on from an engineering perspective.

 

[CSMR]

Am I right in saying that USB jitter doesn't matter because the jitter has no effect on the next stage? Just as when a computer performs a logic operation such as 1 OR 0 = 1 slight inaccuracies in the input signals have no or minimal effect on the output? But when a DAC converts 001100111 to an analog level slight inaccuracies do have an effect on the output?

 

[Wodgy]

No, the jitter coming from USB digital sources still matters (as much as jitter from other digital sources).

Jitter is not an error in getting the right data -- any decent rig should be able to transmit and receive the 0's and 1's perfectly. (Yes, it's true that some computer sources can't even manage this, but most people should be able to find a nice bit-perfect hardware/software combo after reading the forums.) Jitter is variation in the timing of those 0's and 1's. This does matter in digital to analog conversion, depending on the DAC design, and often measurably so (i.e. not just in audiophiles' minds). Stereophile now publishes jitter-induced distortion measurements when they review digital gear, which is nice.

However, it's important to keep this stuff in perspective. Jitter is obviously much less important than getting the right data -- it's more of a "last 10%" thing in terms of sound quality. Also, many high quality DACs reclock their input, significantly reducing the effects of jitter to the point where it's probably not a real issue any more (e.g. Benchmark DAC1, Bel Canto DAC2).

 

[thomaspf]

Well, let's see here

Audio playback over USB needs to be synchronized to the rate at which for example a DVD is playing which requires the illusion of an isochronous stream over a fundamentally packetized bus. If the computer playing the DVD has dramatic variations in speed then you might run into a buffer underrun or overrun if the clock of the digital output on the USB audio device is completely independent. Therefore you slave the output clock of the digital putput somehow to the incoming signal rate. Deep buffering is not a good idea because you loos lip-sync. So far this is all good.

Now what happens if you loose an audio frame. Do you retransmit?

Independent of the question above..

I believe the type of jitter induced by these slow changes of the incoming signal rate over USB should be decoupled from the ps-ns second jitter that induce distortion at this level. I can only bring the example of the flywheel again. You might need to speed up your digital output if your buffers are filling up but you don't do this by introducing random timing variances in the digital oputput stream but by accelerating the flywheel.

@Wodgy
Do I have this more precise now?

Cheers

Thomas

 

[CSMR]

Quote:

Originally Posted by Wodgy No, the jitter coming from USB digital sources still matters (as much as jitter from other digital sources). This does matter in digital to analog conversion, depending on the DAC design, and often measurably so (i.e. not just in audiophiles' minds).

I was suggesting not that it doesn't matter in A-D conversion but in digital-digital conversion. So when you go D-D-D-D-D-D-A only the jitter in the last D matters. If jitter got passed on between digital stages, then perhaps we should start worrying about the jitter of hard drives and their IDE connections, jitter of the CPU etc.. And if jitter were passed on between digital stages, how can computers be reliable?
Is it not the case that as we go between digital stages in a computer, jitter and other imperfections in voltages don't matter in that they have no effect on the next stage, but at the last D-A stage we have to consider the digital signal as an analog one which only approximates the perfect digital waveform because the last transformation is a fundamentally analog one in which imperfections in the input result in differences in the output.
I don't know about how clocks work in computers so this is just a guess - is this on the right lines or not?

 

[Zurg]

Quote:

Originally Posted by CSMR I was suggesting not that it doesn't matter in A-D conversion but in digital-digital conversion. So when you go D-D-D-D-D-D-A only the jitter in the last D matters. If jitter got passed on between digital stages, then perhaps we should start worrying about the jitter of hard drives and their IDE connections, jitter of the CPU etc.. And if jitter were passed on between digital stages, how can computers be reliable?

The root of the problem is that SPDIF is just a crappy digital interface! The flaws in it's specification are well known and published. If your computer used this kind of digital interface between it's components it would likely crash in second. An SPDIF implementation can be completely within spec and will still likely generate errors. Worse, these errors will occur with a periodicity that causes them to be audible. If they were randomly scattered they would be much less detectable. SPDIF is simply an unreliable interface. In normal operation, it does not guarantee the integrity of the data it passes! Apparently, the engineer who designed SPDIF was more concerned about creating a cheap to implement interface, rather than an accurate interface. Now we all get to live with the result.

This has led to high-end devices that go beyond the SPDIF spec to implement "adaptive" interfaces that eliminate most if not all of these errors. Unfortunately, because these fixes are non-standard, they are often expensive and not widely available.

-Z

 

[Glassman]

wel, S/PDIF is perfectly fine for 16/44.1 at least.. bit perfect I mean.. the problem is that the clock is modulated on data and they travel on just one line, not exactly an easy task to reconstruct the clock optimaly..

jitter between digital devices doesn't matter as long as the transfer is asynchronous and that the last digital device is master, not slave.. for example PCI sound cards are masters, they have it's own data buffer and oscilator, they are taking care of filling their buffer as they want, they absolutely do not rely on what they're being sent over the bus.. but with USB the situation is whole different, the USB device is in fact slave and is receiving data frames in certain time periods.. computer is sending data 44.100 times in one second and one second is considered 12 milions of USB's clock periods.. the USB device itself has absolutely no control over that, it must do one think - estimate the real USB clock and lock on that with it's PLL and send out data at that rate.. the PLL is slightly changing it's frequency each data frame received.. the more jittery USB clock is, the more often frequency is adjusted -> jitter..

 

[thomaspf]

USB is a bus where data is traveling in packets interleaved with other other packets.

http://www.usb.org/developers/devclass_docs/frmts10.pdf
http://www.usb.org/developers/devclass_docs/audio10.pdf

describe in some detail what is going on for USB audio class devices. The M-audio sonica is not using the class driver but ships with M-audio's own Audio over USB implementation!

The standard spec allows for various implementations including an asynchronous mode with flow control.

Happy reading

Thomas

 

[Glassman]

oh yeah, but guys at wavelenght audio do not write their own driver, that means they use default usb audio class specification with all of it's shortcommings..

 

[thomaspf]

The USB audio class specification allows for adaptive audio output devices with flow control.

I guess what you are asking is whether the Windows implementation supports that particular mode?

I was under the impression the originator of this thread wanted to know about the Sonica in particular


Quote:

..... I really want to directly couple my Sonica to my Panasonic XR-50 .....

Cheers

Thomas

 

[thefinder]

Is FireWire interface any better in this regard? I know bandwidth-wise Firewire is more preferable than USB, but how about jitter stuff?

 

[arrowmark]

How does one measure jitter?