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.

A refresher course

RG

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!

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

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...