Study: Is I²S interface better for DACs than S/PDIF or USB?

[JoachimStrobel]

The relevance of this I2S discussion seems to be most important for Multichannel. On many forums one can read people trying to access an internal I2S bus to get a handle on non-encrypted MCh audio.
HDMI interleaves SPDIF within the Video signal, and as far as I know, it is only legal to lift an 2 channel stream out into SPDIF, or re-encode Mch with Ac3 into Bitstream over SPDIF.
While the music industry gave up on encrypting red book audio, they have successfully locked away MCh Audio behind HDCP.
And this creates an un-real situation where we have to accept that the Mch´s source (Blueray/DVDA/SACD) digital content needs to be shipped to an external DAC via HDMI and nothing else. (Except an Oppo where a decent DAC is built in).
In the redbook CD world, one could have at least argued that the DAC should be left within the transport for reasons given in previous posts. For Mch there is not such an Option (except the dis-continued OPPO). The non-perfect SPDIF signal is now interleaved with a video signal and encrypted. That seems to be the worst possible solution.
I know of no Blu-ray player with USB-6-channel output. I hear that there are certain professional add-ons to a PC that could generate a 6 channel USB output – but I believe only because somebody did not worry about checking all the licenses needed. There is a product that converts HDMI into SDI and from then onwards audio extraction is easy, but only because the vendor believes that he makes this device for copyright owners only.

So unless I overlooked something, we are stuck with Mch audio in a very uncomfortable situation (locked in HDMI interleaved with Video and HDCP) and I do not see a lot of complaint about this situation. Only the ones that want to find these I2S headers seem to worry.

 

[somebodyelse]

Another possible difference is that USB ports are sometimes, or is that often? shared. So if the USB port to the DAC is shared with other duties then it will be subject to Windows Interrupt regime.

Almost every interface attached to a computer uses interrupts, and shares finite resources. That includes I2S and SPDIF, even when they're 'built in' to the processor like on the Raspberry Pi. It's not safe to say that one is better or worse than the other without looking at implementation specifics - one weak link breaks your audio chain irrespective of interface type. In the case of the Raspberry Pi (<4) there is a weak link related to oversharing the USB-OTG port compounded by something odd about certain programs running that hasn't been fully pinned down. In Windows some users have identified drivers for other devices that increase interrupt latency, causing glitches on their non-USB audio devices - disabling this 'unrelated' driver fixes their audio problems.

 

[DonH56]

Sorry, I do not understand 'cabled interfacing'.
As to I2S my thinking is this: isn't this the interface between the data (eg the CD) and the Digital to Audio Converter. So rather than 'What is the thing about I2S?' My issue is 'Why convert to spdif (or usb) and then reconvert to IS2'. On my system I can interchange between USB and I2S at will. I have done so much A -v- B comparisons that I no longer bother. I have done these comparisons with different bit rates, bit depths, DSD, PCM. At the end of the day I cannot hear a difference. So to me it comes down to theoretical difference: ie what is better in principle? I have mentioned one theoretical difference. Another possible difference is that USB ports are sometimes, or is that often? shared. So if the USB port to the DAC is shared with other duties then it will be subject to Windows Interrupt regime.

Cabled as in the cable from one box to another, like the CD player to the digital-to-analog converter (DAC). Again as far as I know, I2S was designed as an internal connection, not box-to-box. As I hopefully made clear in my previous post I do not track this; it is not my field of expertise, and not something I feel at all strongly about.

When I looked at a few DAC data sheets some accepted PCM via I2S and some included an on-chip USB interface. I did not look hard. Many connections among devices (USB, Ethernet, PCIe, SAS/SATA, etc.) separate the transport layer from the physical layer. S/PDIF and USB are well-known standards; I do not know about I2S. And I mean that literally; I do not know -- last I worked with I2S it was pretty much an "ad-hoc" interface (as is SPI for the most part). Getting the data from A to B quickly and accurately is the goal and any protocols incorporating high speeds and greater error correction and such would seem to be desirable. Some interface protocols support error correction and retries; for CDs, there is no retry, and error correction is encoded into the data stream, so I would expect it to be somewhat agnostic of the interface. Your listening tests seem to bear that out.

Any interface is subject to the OS once you have a computer in the system. Whatever interface you use, the OS is not generally going to spend 100% of its time looking at it. The OS will be doing many things and has to interrupt (or poll) the port to grab the data no matter the interface. Most (probably all) hardware solutions include on-chip buffers to reduce their sensitivity to OS latency.

Anyway, I freely admit I am out of my depth on this one, it just caught me off-guard based on my limited experience with I2S. I could not think of an immediate advantage, and separating the clock I have seen cause problems in other systems, so was confused.

No worries - Don

 

[tohoho4]

I2S input on my Sabaj D5 is the only way to listen SACDs played on my Sony UBX 800M2. HDMI ARC outputs to a HDMI to I2S converter which outputs DSD over I2S to Sabaj D5 via HDMI connector.View attachment 36803

I also bought the HDMI Audio Separation and Extraction board from aliexpress ( https://www.aliexpress.com/item/33031920347.html?spm=a2g0o.productlist.0.0.1d073d68KWGTzQ ), and compared 1kHz sine waveforms played from DSD file by my Sony UBP-X800M2 (one was converted to PCM format within the UBP-X800M2 and transferred to Sabaj D5 via coaxial (spdif) port of UBP-X800M2 as PCM format, the other was transferred to Sabaj D5 via HDMI audio port of UBP-X800M2 via I2S output port of HDMI Audio Separation and Extraction board as DSD format).

 

[Arvind]

I also bought the HDMI Audio Separation and Extraction board from aliexpress ( https://www.aliexpress.com/item/33031920347.html?spm=a2g0o.productlist.0.0.1d073d68KWGTzQ ), and compared 1kHz sine waveforms played from DSD file by my Sony UBP-X800M2 (one was converted to PCM format within the UBP-X800M2 and transferred to Sabaj D5 via coaxial (spdif) port of UBP-X800M2 as PCM format, the other was transferred to Sabaj D5 via HDMI audio port of UBP-X800M2 via I2S output port of HDMI Audio Separation and Extraction board as DSD format).View attachment 40093View attachment 40094

Very useful comparison. I use I2S input only for SACD dsd or DVDA playback. For CD, me too prefer coaxial one. I will be grateful if you could compare dsd playback from sacd with dsd converted to pcm.

 

[tohoho4]

Because I don't have audio check SACD, I could not compare 1kHz sine wave. As the next best way, I used the biginning of the SACD (Maher Symphony No.1, RCO, Mariss Jansons). Here is the results youtube video.

Caution : The input gain of recorder (Roland Rubix22) is same between Coax(SPDIF) recording and HDMI (I2S) recording, but DAC output level (sabaj D5 RCA out) of HDMI (I2S) is about 10dB higher than that of Coax(SPDIF).

 

[Arvind]

Because I don't have audio check SACD, I could not compare 1kHz sine wave. As the next best way, I used the biginning of the SACD (Maher Symphony No.1, RCO, Mariss Jansons). Here is the results youtube video.

Caution : The input gain of recorder (Roland Rubix22) is same between Coax(SPDIF) recording and HDMI (I2S) recording, but DAC output level (sabaj D5 RCA out) of HDMI (I2S) is about 10dB higher than that of Coax(SPDIF).

Thanks tohoho4
Apparently I2S extractor is inducing some spurious tones. But is there any other way to play sacd layer on this player?

 

[tohoho4]

But is there any other way to play sacd layer on this player?

SACD layer`s DSD data can be directly transferred to some AV recievers via HDMI cable. But it is probably the same results as my measurements (HDMI transfer has more spurious tones than Coax transfer).

Another remarks reagarding to the above measurements : DSD files are converted to 192kHz sampling PCM format within the UBP-X800M2, but SACD disk are converted to 44.1kHz sampling PCM format within the UBP-X800M2.

 

[Arvind]

SACD layer`s DSD data can be directly transferred to some AV recievers via HDMI cable. But it is probably the same results as my measurements (HDMI transfer has more spurious tones than Coax transfer).

Another remarks reagarding to the above measurements : DSD files are converted to 192kHz sampling PCM format within the UBP-X800M2, but SACD disk are converted to 44.1kHz sampling PCM format within the UBP-X800M2.

In my setup sacd playback outputs dsd (and not converted to pcm) to Sabaj via said I2S converter and dsd being played back is displayed on sabaj.

 

[tohoho4]

In my setup sacd playback outputs dsd (and not converted to pcm) to Sabaj via said I2S converter and dsd being played back is displayed on sabaj.

Me too. But disconneted HDMI cable and connected to Sabaj via coaxial cable and played DSD file or SACD disk, then Sabaj display show PCM frequency that was converted within player.

 

[Eirikur]

Perhaps I know too little about I2S, but it seems like a very poor machine to machine interface when compared to SPDIF.

• I2S operates at 50% duty cycle compared to the same data stream over SPDIF
  • This implies a higher jitter bandwidth for I2S
• Clock and signal have separated wires in I2S, while SPDIF cleverly encodes it in the signal
  • In I2S we now have two three sources of potential interference with the clock...
  • (Three sources: I forgot the word selector)

For short distance internal transfer it makes sense to use the separated clock and signal, but on the external interface it is a strange move.
Please educate me as to why I2S makes sense as a component interface... (I truly cannot think of any advantage)

PS: just look at PC hard-drive interfaces: here they made a decisive shift from parallel to (differential) serial data communication, using a clever 8b/10b coding rather than the robust brute-force (but signal phase independent!) bi-phase mark code in the S/PDIF approach.
Note that both DAT and DCC also use the 8b/10b approach, while CD, SACD, DVD and the like use a wider version of the same principle (EFM, EFMplus) - nothing new here!

[EDIT] One I2S application I can think of: tapping into the SACD digital signal that is otherwise unavailable

 

[tohoho4]

Perhaps I know too little about I2S, but it seems like a very poor machine to machine interface when compared to SPDIF.

• I2S operates at 50% duty cycle compared to the same data stream over SPDIF
  • This implies a higher jitter bandwidth for I2S
• Clock and signal have separated wires in I2S, while SPDIF cleverly encodes it in the signal
  • In I2S we now have two three sources of potential interference with the clock...
  • (Three sources: I forgot the word selector)

For short distance internal transfer it makes sense to use the separated clock and signal, but on the external interface it is a strange move.
Please educate me as to why I2S makes sense as a component interface... (I truly cannot think of any advantage)

PS: just look at PC hard-drive interfaces: here they made a decisive shift from parallel to (differential) serial data communication, using a clever 8b/10b coding rather than the robust brute-force (but signal phase independent!) bi-phase mark code in the S/PDIF approach.
Note that both DAT and DCC also use the 8b/10b approach, while CD, SACD, DVD and the like use a wider version of the same principle (EFM, EFMplus) - nothing new here!

[EDIT] One I2S application I can think of: tapping into the SACD digital signal that is otherwise unavailable

Thank you for your technical explanation. So when using I2S over HDMI transfer, it seems better to use AV reciever rather than using external I2S extractor, because AV reciever have internal I2S extractor and becomes I2S cable length short and interferances between clock and signals small. And when using external I2S extractor, HDMI cable length between external I2S extractor and Sabaj HDMI (I2S) input should be as possible as short.

 

[amirm]

In high-end audio, I2S is transmitted on HDMI *cable*. It has nothing to do at all with HDMI as an interface.

Audio in a proper HDMI interface is embedded as data in the unused areas of video frame. In high-end audio application, there is no video of course. So we really should not talk about I2S in the context of HDMI.

 

[tohoho4]

I2S cable connection is originally considered as DAC chip interface within DAC board, so it seems as possible as short length is preferable. I tried to compare the defferences of HDMI cable length ( 1m and 2m) between external I2S extractor HDMI (I2S) output and Sabaj D5 HDMI (I2S) input (HDMI cable length between UBP-X800M2 HDMI audio out and external I2S extractor HDMI input is same length). the results is that 1kHz sine wave spectrums are almost same between 1m cable and 2m cable, but the probability of sound interruption almost disappeared when using short 1m HDMI cable.

 

[Arvind]

I2S cable connection is originally considered as DAC chip interface within DAC board, so it seems as possible as short length is preferable. I tried to compare the defferences of HDMI cable length ( 1m and 2m) between external I2S extractor HDMI (I2S) output and Sabaj D5 HDMI (I2S) input (HDMI cable length between UBP-X800M2 HDMI audio out and external I2S extractor HDMI input is same length). the results is that 1kHz sine wave spectrums are almost same between 1m cable and 2m cable, but the probability of sound interruption almost disappeared when using short 1m HDMI cable.

I have already ordered 30cm hdmi cable for I2S transfer.

 

[captain paranoia]

Still rather disappointed that a thread entitled 'Study: Is I²S interface better for DACs than S/PDIF or USB?' still hasn't been updated to reflect revised findings.

The title says DACs: plural. Only one DAC has been tested. When the clock recovery was disabled, I2S was shown to be better than SPDIF. I am not at all surprised by this result (hence my comment on P4).

For a forum intended to be objective, there appears to be another dig at a 'personality'.

Let me be clear: I think PS Audio products are shown to be poor, and Paul McGowan appears to be a bullshitter.

But if I found that I had published a review where I had not configured the interface correctly, and I discovered that, in some cases, there was some merit in the claim (even if it only applies to poorly-designed DACs), I would have corrected the OP.

That's what an objective, science-based review would do.

if your aim is to be objective, be objective. If your aim is to have a dig at subjectivist bullshitters, don't try claiming to be objective.

 

[amirm]

When the clock recovery was disabled, I2S was shown to be better than SPDIF.

That's like saying if you took out the springs out of your suspension your car rode better on one tire versus the other. Clock recovery over S/PDIF is required and once there, there is no advantage here.

Even if we went with that scenario, there is no audible difference whatsoever:

Spurious tones are < -120 dB.

 

[amirm]

Still rather disappointed that a thread entitled 'Study: Is I²S interface better for DACs than S/PDIF or USB?' still hasn't been updated to reflect revised findings.

The title says DACs: plural. Only one DAC has been tested.

You are welcome to sit in a haunted house every day of the year to see if a ghost shows up. Me, if I know such things are impossible and still sit there one full night, that is all I need.

It is not like I am sitting around with nothing to do. I have weeks worth of equipment waiting to be reviewed every day of the week. With people who have supported the forum by sending equipment to me at their expense (and mine when I send them back).

So consider the situation before making such remarks.

 

[captain paranoia]

I don't expect you to test lots of DACs (that wasn't my point at all). But if you're going to post a thread that talks in general terms about interfaces and DACs (plural), but only demonstrate with one DAC, it's not a valid title, or experiment. It's anecdotal evidence. Anecdotal evidence isn't science, remember? And this is supposed to be Audio Science Review. The only thing I did expect was for the OP to be editied to provide a more accurate presentation of results, and a less coloured conclusion. Rather than have the clarification buried deep within the thread.

My point about clock recovery is that not all DACs have good clock recovery. Obviously, all SPDIF DACs have to recover the clock from the biphase encoded data, but they won't all do it as well. You've even demonstrated that.

So, the scientific approach is to provide an accurate description of the findings:

For a DAC with good clock recovery, SPDIF is as good as I2S.
For a DAC with poor/degraded clock recovery, there may be some benefit for an I2S interface
The I2S interface is as good as a DAC with a well-engineered SPDIF interface.

None of these conclusions points to I2S being a bad idea as a DAC data interface. The conclusion does point to the need for a DAC with a well-engineered SPDIF interface.

Even if we went with that scenario, there is no audible difference whatsoever:

Your standard measurements include jitter measurements. You comment on how good some of these jitter measurements are. I completely agree that the level of spurious shown by that DX3 will be inaudible, but I suspect that, in a comparative conclusion, you would say that the Gustard was better; your reviews usually include such comparative comments. Clearly, you think it is worth presenting and commenting on the performance, even if inaudible.

I was attracted to this site because it appeared to be dedicated to proper engineering, free from woo and personalities, and, above all, providing an objective discussion of audio equipment. If that's not the way you want it to be, ignore my observations. If you want the same as I do, maybe sit back and think about what I've said, without being quite so defensive.

 

[Veri]

For a DAC with good clock recovery, SPDIF is as good as I2S.
For a DAC with poor/degraded clock recovery, there may be some benefit for an I2S interface
The I2S interface is as good as a DAC with a well-engineered SPDIF interface.

These are pretty big assumptions. Just FYI, any USB DAC is converting to I2S before feeding it to the DAC chip, S/PDIF be damned.

Why would some external device outputting I2S(a protocol to communicate between chips, and thus not designed to transfer over lengths of cable at all), be any better than plugging in the USB cable and be done with it?

I think Amir's conclusions are sound. There's plenty of graphs in this thread that show there's little point to go the I2S route.