Battle of S/PDIF vs USB: which is better?

[gvl]

I think the non-standardized I2S thing (HDMI connector, right?) is about features. Like higher res.

Usually HDMI or RJ-45. The former is using differential signaling, the latter is typically just straight wire. Pinouts are not standardized.

 

[DonH56]

I thought RJ-45 used twisted pairs and differential signalling? Not my area of expertise but cables I have assembled are twisted pairs and the transceivers are differential.

 

[gvl]

I thought RJ-45 used twisted pairs and differential signalling? Not my area of expertise but cables I have assembled are twisted pairs and the transceivers are differential.

When they are used for Ethernet/networking with long runs. I2S is not standardized, they just use it as a connector with a simple wiring scheme.

 

[DuxServit]

So people are now using an interface designed only to be used between chips on a PCB as the physical interface from the outside world? All because they think it gives better quality bits?

What should be the reaction to such an idea? To laugh at it then ignore it, or set up a series of highly controlled listening tests? To many people it's the latter because they think that's science. But in fact this is a man-made system and doesn't need to be observed like the natural world. Using I2S as the interface to the outside world is just stupid and doesn't need to be tested in order to dismiss it.

So there is some lengthy discussions over at the PS Audio forum about this (DirectStream supports I2S/LVDS). My limited understanding is that I2S is of interest to folks looking for better ways to transmit DSD (e.g. from their sources). But with DoP this can be achieved without I2S (e.g. using USB or Ethernet).

 

[gvl]

DoP limits max DSD rate.

 

[Fitzcaraldo215]

So there is some lengthy discussions over at the PS Audio forum about this (DirectStream supports I2S/LVDS). My limited understanding is that I2S is of interest to folks looking for better ways to transmit DSD (e.g. from their sources). But with DoP this can be achieved without I2S (e.g. using USB or Ethernet).

Well, like many things in audio, especially computer audio, there is no completely rational reason for many fringe tribal movements. The I2S idea seems to stem from the "dear God, absolutely no USB under any circumstances" chorus over at CA and in other epienters of digital sophomorism. As far as I know, there are no published measurements that demonstrate any superiority of I2S/spdif over asynch USB. None. Am I wrong?

Meanwhile, over in USB Land, everything is just fine. The I2S guys problems are already solved on this side of the great divide. PCM and DSD transmit at blistering speeds, even in multichannel, with jitter pretty much banished. And, no need for klutzy DoP. Agreed some DACS have poorer isolation, but easy to avoid those. Just read Amir's measurements.

 

[gvl]

Until fairly recently USB was limited to DSD256 with off the shelf solutions, I2S was/is a way to support higher rates and some future proofing.

 

[watchnerd]

Crikey this is a lot of work converting all these standards.

I just use ethernet.

 

[Fitzcaraldo215]

Until fairly recently USB was limited to DSD256 with off the shelf solutions, I2S was/is a way to support higher rates and some future proofing.

Yes, many DACs were limited to DSD256 by their DAC chips, not at all by USB. There is plenty of bandwidth in USB to go much, much higher, way beyond any conceivable audio data rate, as if we needed to do that. When I listen to 5-channel DSD256 recordings now via my DAC, the asynch USB connection is still only using a fraction of its capacity.

Future proof? God help us if the best we can do is to get into a pointless race to see who can one up everyone else in sampling rate to become King of the Hill. But, USB is the better answer even to that ridiculous scenario.

 

[Fitzcaraldo215]

Crikey this is a lot of work converting all these standards.

I just use ethernet.

I would gladly try that too, but DACs with Ethernet input are a rarity, meaning typically a conversion device to USB, spdif, etc. is necessary.

 

[Sal1950]

Usually HDMI or RJ-45. The former is using differential signaling, the latter is typically just straight wire. Pinouts are not standardized.

At least RJ-45 has the little locking lever. I hate all the modern connectors that are just the slightest tug away from either an intermittent connection or falling out completely. IMHO, that's just stupid.

 

[gvl]

Yes, many DACs were limited to DSD256 by their DAC chips, not at all by USB. There is plenty of bandwidth in USB to go much, much higher, way beyond any conceivable audio data rate, as if we needed to do that. When I listen to 5-channel DSD256 recordings now via my DAC, the asynch USB connection is still only using a fraction of its capacity.

Future proof? God help us if the best we can do is to get into a pointless race to see who can one up everyone else in sampling rate to become King of the Hill. But, USB is the better answer even to that ridiculous scenario.

There is definitely enough bandwidth headroom in the wires. The limitation is the async endpoint, I believe even the latest chips are limited to 32bits/ 768kHz or up to DSD512. The latest ES9038PRO DAC supports DSD1024, the only way to supply a DSD stream to the DAC chip at that rate is I2S. Why would you need such rates is a separate question, but there is a theory that external conversion to high DSD rates in software such as HQPlayer can have positive effect on the sound quality.

 

[watchnerd]

I would gladly try that too, but DACs with Ethernet input are a rarity, meaning typically a conversion device to USB, spdif, etc. is necessary.

TEAC, NAD, Devialet.....I'm sure there are more.

True, they're not ubiquitous, but there are options, and at differing price points.

 

[captain paranoia]

So people are now using an interface designed only to be used between chips on a PCB as the physical interface from the outside world? All because they think it gives better quality bits?

There are two possible arguments I can think of:

1) I2S has a dedicated, continuous clock. Therefore, we don't need to recover clock from the data stream (as we do in SPDIF). This has the potential for lower jitter.

2) I2S is the native output from CD data recovery circuits, and also the native input for many DAC chips (since the interface is intended to connect two two circuits on a PCB...). Therefore, you don't need encoding and decoding interfaces between the two ends (e.g. I2S to SPDIF, and SPDIF to I2S). Less is more, right...?

Adding appropriate line driver and receiver buffers to allow I2S signals to be sent between units isn't that big a deal.

Note that I'm not saying it's a work of genius, just that it's not a completely unreasonable idea.

 

[Cosmik]

There are two possible arguments I can think of:

1) I2S has a dedicated, continuous clock. Therefore, we don't need to recover clock from the data stream (as we do in SPDIF). This has the potential for lower jitter.

2) I2S is the native output from CD data recovery circuits, and also the native input for many DAC chips (since the interface is intended to connect two two circuits on a PCB...). Therefore, you don't need encoding and decoding interfaces between the two ends (e.g. I2S to SPDIF, and SPDIF to I2S). Less is more, right...?

Adding appropriate line driver and receiver buffers to allow I2S signals to be sent between units isn't that big a deal.

Note that I'm not saying it's a work of genius, just that it's not a completely unreasonable idea.

I don't think "clock recovery" from S/PDIF is all that big of a deal. In reality I think it is little more complex than getting it from separate clock/data lines. The jitter comes from analogue noise affecting the detection of the exact transition point of the binary signal, and so whether it's I2S or S/PDIF I think you would need some sort of PLL-type fly-wheel arrangement to average the detected period in order to get good jitter performance after receiving the signal over a cable.

Standard I2S is not 'hardened' for transmission over cables. I don't know whether they are buffering it, adding ESD and RFI absorbing components, using hysteresis on the input, etc. In the unlikely event they are, if I were them I would invent a new marketing name like 'I2S CABLE+' or some such.

 

[captain paranoia]

Clock recovery from a self-clocked data signal is significantly more of a deal than a stream with separate clock and data. It's not just about the clock edge (there isn't a clock edge...). It requires you to generate a clock from the incoming signal. Optical SPDIF has poorer jitter because of the cheap (slow transition times) optoelectronics and plastic fibre; jitter depends on the noise and the edge slew rate. See my thoughts on clock recovery earlier in the thread. I'm happy to have a simple SPDIF clock recovery scheme shown to me; always stuff to learn... Maybe I need to go and have a look at some SPDIF/I2S converter data sheets.

SPDIF isn't 'hardened' any more than a normal digital line Tx/Rx. There is no error correction mechanism. There would be no difference between SPDIF and I2S with proper driver/receiver pair; you could use whatever tx/rx pair you wanted; USB, LVDS, etc.

As I said, I'm not arguing that I2S is the best way of doing things, just that it isn't completely unreasonable. I'm very much of the opinion that the data source should be a timing slave, with the DAC as timing master, using FIFO buffers and a flow control protocol. But that requires a much more sophisticated interface between units (whereas it is much easier to build into a standalone CD player; you slave the CD servo to the DAC data clock).

 

[gvl]

There are polished solutions for SPDIF clock recovery with minimal resulting jitter, WM8805, etc. There is no difficulty, just use a cookbook approach. That said it would be interesting to somehow compare I2S vs. SPDIF jitter performance on a DAC that supports both with a high-quality external I2S source.

 

[captain paranoia]

Yes, you can buy integrated solutions, but they hide the complexity of what they're doing. Clock recovery is more complex than a simple, supplied clock.

It would be interesting to see whether the clock recovery is good enough to keep the jitter lower than a direct clock (with jitter caused by noise and slew rate on the clock signal). PLL phase noise vs signal noise (on top of the source clock phase noise...).

I might dig around the Wolfson stuff to see if I can figure out their recovery approach, out of curiosity. And have a chat with one of my colleagues who is a clock synthesizer guru.

 

[amirm]

I have a USB to I2S interface (I think). Is there a cheap DAC with both in them to test against?

 

[gvl]

I haven't seen truly cheap DACs with I2S. The cheaper are probably the Audio GD variety.