DCS-I2s-airlens

I have a Bartok and i love it.But technology continues envoling.So i am curious of some one here already tried thé ps-audio Airlens streamer in combination with a dCS DAC/streamer like Bartok,Rosinni,Vivaldi,etc.
I know dCS have no I2s inputs,but i now inside thé streamer off Bartok and others are connected with I2s to DAC.
is there any difference/better then thé internal streamer using RCA input?
Can a dCS upgrades with a I2s input and Will be that improvement at all?
Thx For reading and i am looking forward to your comments.

Just my personal opinion;

There is no benefit to having a native I²S inputs other than for vendors who have poor AES/SPDIF implementations in their products; they opt to include an I²S so that they don’t have to depend on their weak/jitter-prone AES/SPDIF implementation. As such, having an I²S interface on a Streamer/DAC is not en “evolution”, it’s a solution to the problem some vendors have.

With the dCS products, one can objectively prove bit-perfect AES/SPDIF to I²S conversion internally with their Streamers, so, there’s no need for native I²S interface.

3 Likes

Hi Rudi,

The reason that I²S is very popular amongst some audio products is that it is the standard protocol for pretty much all audio chips (off the shelf DAC chips, filters, asynchronous sample rate converters, SPDIF receivers, CD transports etc.). It has been around for a very long time, there’s only a few wires, and you essentially just wire everything together, making it very easy to implement.

The catch is that I²S has been designed to connect chips together on a board, meaning with PCB tracks, that are carefully routed so the delays and impedance are carefully matched. When that signal is sent over, let’s say, an HDMI connector and cable, the first thing to consider is the skew of the signals. Because there are multiple wires, with one of the wires providing the clock for another wire’s data, any mismatch will cause horrible crackling as the data is decoded incorrectly.

Then, there is an issue with impedance mismatches causing reflections in the cable – and because the clock is generally high speed, often just moving the cable can cause issues, ranging from increasing jitter to (again) bad crackling. This is why HDMI is typically used as the connector/cable of choice. The HDMI standard runs at very high rates, so the tolerances on HDMI cables are generally pretty tight. If you add to this the fact that it’s a raw audio interface (no other useful data like with S/PDIF), changes to the playback chain such as switching sample rates are going to cause bangs through the system.

In the real world, I²S over HDMI will probably have higher jitter than a correctly implemented S/PDIF connection - because the source is transmitting a raw clock over a long way, and because it is just a raw audio signal you can’t use a PLL to filter out any interface jitter.

The reason S/PDIF was invented was because I²S is unsuitable for transmitting audio over any distance – HDMI coming along has helped I²S work for some companies, but that doesn’t alter the fact it’s not a format that we deem as appropriate to use in this way, especially considering formats like S/PDIF exist specifically for this purpose.

11 Likes

Thanks James, that is now very clear.