You are here

Log in or register to post comments
bifcake
bifcake's picture
Offline
Last seen: Never ago
Joined: Nov 27 2005 - 2:27am
PCM over USB

Could someone explain to me in layman's terms why it is that PCM streams going over the USB exhibit a much greater amount of jitter than when they're going over the coax interface?

It seems to me that USB already has clocking and error correction built-in as part of its spec. So, the USB should exhibit practically no jitter at all. Am I missing something?

Thanks

struts
struts's picture
Offline
Last seen: 3 days 8 hours ago
Joined: Feb 1 2007 - 12:02pm
Re: PCM over USB

Alex,

Let me take a crack at this. I approach this as an electronic engineer and computer geek rather than as a professional USB audio system designer, but enough of the latter frequent this board that I am sure they will pull me up if I veer too far off track!

The root of the explanation lies in the fact that the USB interface was not designed to stream audio at an exact and constant rate. So unlike S/PDIF it does not carry a clock signal. It has different modes of operation where either the sender (synchronous mode) or the receiver (asynchronous mode) clock the data, each of which has its own problems and trade-offs. Ultimately it comes down to two things (i) how accurate is the 'master' clock and (ii) how tightly is the 'slave' locked to it. The answer to both in most typical USB audio applications is 'not very'.

Companies like Wavelength Audio and Benchmark Audio have worked around these issues in various clever ways and you'll find lots of information on their respective websites.

As an aside S/PDIF (which I know a lot more about, hey it even existed back when I was studying engineering which USB certianly didn't!) was designed to stream audio, but compromises in the design of the interface allow jitter to creep in which is very difficult to eliminate without completely reclocking the data. The only interfaces that avoid this problem are ones that pass the clock and the samples independently such as I2S.

I hope this helps. Your question is a great one but really very difficult to answer fully without getting extremely technical.

bifcake
bifcake's picture
Offline
Last seen: Never ago
Joined: Nov 27 2005 - 2:27am
Re: PCM over USB

Struts,

Since USB has native clocking data, then wouldn't it make sense to encapsulate PCM stream within the USB wrapper, send it to the DAC, which would buffer it and reassemble the stream and feed it to the converter? Ethernet wasn't designed for video or audio streaming either, yet there are no clocking issues with using that.

RGibran
RGibran's picture
Offline
Last seen: 2 years 4 months ago
Joined: Oct 11 2005 - 5:50pm
Re: PCM over USB
bifcake
bifcake's picture
Offline
Last seen: Never ago
Joined: Nov 27 2005 - 2:27am
Re: PCM over USB

Thanks. I had forgotten about that thread.

I wonder though... It's been almost two years since that post and I would have thought that by now, new DACs would incorporate the advanced USB features and include clocking in the USB digital audio stream. I am surprised that this hasn't happened yet. Are they simply taking the regular PCM stream and sending it over an USB interface or are they actually re-engineering the digital flow to take advantage of the USB interface?

struts
struts's picture
Offline
Last seen: 3 days 8 hours ago
Joined: Feb 1 2007 - 12:02pm
Re: PCM over USB

Alex,

I think there's a tiny bit of confusion creeping in here because you're comparing apples and oranges.

Analogies are always dangerous because they tend to break down at some point (or, even worse, get turned against you!) but think of it as the difference between transporting water in buckets versus a pipe. To create a steady stream at the far end from buckets you need a reservoir with a tap and the rate the buckets fill the reservoir needs to be controlled based on how open the tap is so that the reservoir neither runs dry or overflows.

Ethernet is not suitable for or capable of supporting audio streaming, it is purely a 'buckets' protocol. When ethernet is used in audio applications it is to transport encoded files (e.g. FLAC, WAV) only. Transferring a FLAC file is like transporting a DOC or XLS file, the encoded information has no timebase so the concept of jitter does not apply. The timebase is created by the wordclock at the point of conversion back to analogue. Any audio device with an ethernet interface therefore has to, by defintion, contain a decoder, a buffer and a clock, none of which are prerequisites for USB.

You could say that USB has modes equivalent to both bucket and pipe, it is just that the pipe mode was not really designed with the precision required by streamed audio in mind. It is quite a 'stuttery' pipe which is why you often hear people complain about pops and clicks when using USB interfaces for audio. It is not so much a question of 'taking advantage' of it as minimizing your dependency on it.

One way you can do this is to treat it more like buckets (even if you're using it in 'pipe' mode) with a reservoir etc. I believe this is the approach that Benchmark uses in the DAC 1 USB; they have a big buffer and generate a precision clock outside the PC, intelligently controlling the flow into the buffer so it neither empties nor overflows. There may be other strategies, I really don't know.

However at the end of the day it is all about flow control. You don't want to 're-engineer' the PCM samples because they are all your DAC understands. All (ha!) you need to do is ensure that they are available to the DAC at a rate that over the long term exactly matches the clock frequency and that you have a buffer that is big enough to deal with any short-term variation.

I hope this helps!

bifcake
bifcake's picture
Offline
Last seen: Never ago
Joined: Nov 27 2005 - 2:27am
Re: PCM over USB

Thanks Struts, that's a very good explanation.

Re: DAC1, I vaguely remember reading I think a Stereophile review of DAC1, which mentioned jitter rate of over 600 picoseconds over the USB vs 200 something vs coax.

Editor
Editor's picture
Offline
Last seen: 4 years 2 months ago
Joined: Sep 1 2005 - 8:56am
Re: PCM over USB


Quote:
Ethernet is not suitable for or capable of supporting audio streaming, it is purely a 'buckets' protocol. When ethernet is used in audio applications it is to transport encoded files (e.g. FLAC, WAV) only.

Ethernet audio streaming can be made to work. We have a review of the Linn Klimax DS in our March 2008 issue, and I have just finished testing the piece. There doesn't seem to be any technical issues that result from it being fed data from a NAS drive via Ethernet.

John Atkinson
Editor, Stereophile

bifcake
bifcake's picture
Offline
Last seen: Never ago
Joined: Nov 27 2005 - 2:27am
Re: PCM over USB

John,

Would I be correct to assume that as long as the stream is going over the Ethernet, there should be no jitter? Am I also correct to assume that if USB protocol was fully utilized for streaming, there wouldn't be jitter issues either?

Thanks

struts
struts's picture
Offline
Last seen: 3 days 8 hours ago
Joined: Feb 1 2007 - 12:02pm
Re: PCM over USB

John,

I think we're at cross purposes here. You are correct, but I was attempting to make a different point and in trying to simplify things I may have expressed myself unclearly.

The origin of the discussion was AlexO asking the question why jitter was a problem with USB but not with, say ethernet. My point was to try to explain that you cannot stream 'raw' PCM over ethernet, only encoded in audio files which by definition just contain word samples, no timing information, and therefore cannot possibly be susceptible to jitter. USB can do both, i.e. stream encoded files or stream PCM with a wordclock, it just happens to do the latter rather poorly resulting in jitter and/or dropouts leading to pops, clicks etc.

Clearly, many audio file formats are designed to be 'streamed' in the sense that they are designed so that the decoder can start processing the start of the file before the whole file has been received. This necessitates a buffer and a flow control mechanism to ensure the buffer doesn't empty or overflow, but flow control of 'streaming' over ethernet still does not imply that any clock information is being passed over the ethernet link. The clock only comes into play once the samples in the decoded file start being handed to the DAC for conversion.

This is different to synchronous implementations of USB 'streaming' where PCM data and clock information are passed from the sending unit. An M-Audio Transit, for instance, doesn't have a clock inside it because it doesn't need one, it takes its clock from the host PC.

So I would still maintain that ethernet is a 'buckets' protocol that cannot support a 'true' stream in the same sense a S/PDIF 'pipe' can, but agree that files can indeed be streamed over ethernet using something akin to 'buckets filling a reservoir' in a way that produces a similar result.

I knew I would end up tying myself in knots. Oh well...

  • X
    Enter your Stereophile.com username.
    Enter the password that accompanies your username.
    Loading