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

[jjk]

It's definitely native I2S.
It is also odd to me that some peeps are fighting so hard against I2S as implemented by PinkFaun.
Dudes! Forget the USB! It doesn't have anything to do with I2S in this case.
If it's USB, how am I getting 8 discreet channels?

 

[garbulky]

Well you need to interface on something, right...

I mean if you are already on USB - what's the point of then going to a second interface? You are already now streaming the digital data using USB. Just use USB. Amir says it generates the source again which is true - but it's re-generated from a streaming source. I assume it is reclocked at this point. So here we are assuming that this original streaming source was received perfectly and regenerated perfectly. A better study would use something like that Piunk I2s bridge. Where the streaming originates with I2S. You could then use an SPDIF output from the same PC and compare the two.

 

[garbulky]

My understanding is that it is a native I2S source. The Pink Faun Audio Bridge that I have is here . There is no USB in sight. It operates like any soundcard and goes direct to the DAC. That is, providing the DAC has an I2S input. This latter point is a little tricky as there is no standardised pin alignment. However Pink Faun will be accommodating in ensuring that their output and your input will match.

You seem just the person to ask this.
I am looking for basically this:
https://www.pinkfaun.com/shop/bridge/45-2880-spdif-bridge.html

However....I am interested in a single two channel AES output instead of SPDIF and BNC. The other two outputs don't have to be there though they can be. Do you know where I can find one?

Note: What I don't want is an onboard DAC or a breakout AES cable snake with like 5 AES cables like in those RME/Lynx professional cards - just a simple AES output from a PCI-e card.

To be clear - not looking for something like this:

 

[Veri]

Note: What I don't want is an onboard DAC or a breakout AES cable snake with like 5 AES cables like in those RME/Lynx professional cards - just a simple AES output from a PCI-e card.

You could get something like a Lynx, and a custom breakout cable to only AES. See for example this:
https://www.superbestaudiofriends.o...-breakout-cables-pcie-expansion-chassis.8355/

 

[Zog]

You seem just the person to ask this.
I am looking for basically this:
https://www.pinkfaun.com/shop/bridge/45-2880-spdif-bridge.html

However....I am interested in a single two channel AES output instead of SPDIF and BNC. The other two outputs don't have to be there though they can be. Do you know where I can find one?

Note: What I don't want is an onboard DAC or a breakout AES cable snake with like 5 AES cables like in those RME/Lynx professional cards - just a simple AES output from a PCI-e card.

To be clear - not looking for something like this:

On the page you link to there is a drop down menu under the heading SPDIF output options. This includes AES/EBU. I found Jord to be easy to deal with and you can certainly email them.

 

[jjk]

Jord is a great guy.
I am lucky in that I travel frequently. I have visited Jord twice at his shop in Rhenen.
I had lunch with him last month.
He will provide outstanding information and great service. Highly, highly recommended!
Rhenen is located along the lower Rhine, several miles from an incredibly historic area: Oosterbeek and Arnhem, scene of one of the most famous battles of WW II.

 

[garbulky]

On the page you link to there is a drop down menu under the heading SPDIF output options. This includes AES/EBU. I found Jord to be easy to deal with and you can certainly email them.

WOW! You are right. I can't believe they have it! This is what I've been waiting for! I can finally use the AES on my DC-1 DAC.

 

[garbulky]

You could get something like a Lynx, and a custom breakout cable to only AES. See for example this:
https://www.superbestaudiofriends.o...-breakout-cables-pcie-expansion-chassis.8355/

Ahhh cool find. I don't think I want to go that route. I was specifically looking for a dedicated two channel device like the one that @Zog listed. I've been looking for such a thing for many years now. I can't believe I found it!

 

[FrantzM]

I have an interesting snippet from one of the PS audio forums.

View attachment 24007

In other words, it looks as though - in this implementation anyway - I2S is being used as the exact equivalent of S/PDIF.

Indeed!
Seems that for the audiophile, i2S is a solution looking for a (solved) problem..

 

[DonH56]

I am struggling to see why anyone cares about I2S these days but it is not something I have paid any attention to. I thought it was an old standard for IC connections, not cables (Inter-IC Sound, in contrast to the widely-used but not really related I2C (Inter-IC) interface) and that everyone pretty much used AES or S/PDIF instead? Don't really know, but what are its claimed advantages over AES3 or whatever? Seems like I2S, at least my very foggy memory of it, is not nearly as robust as AES for cabled interfacing (e.g. outside the box). Again, based on my vague memory that it was meant to be a short-length solution inside the box (chip-to-chip, not box-to-box).

 

[Cosmik]

I am struggling to see why anyone cares about I2S these days but it is not something I have paid any attention to. I thought it was an old standard for IC connections, not cables (Inter-IC Sound, in contrast to the widely-used but not really related I2C (Inter-IC) interface) and that everyone pretty much used AES or S/PDIF instead? Don't really know, but what are its claimed advantages over AES3 or whatever? Seems like I2S, at least my very foggy memory of it, is not nearly as robust as AES for cabled interfacing (e.g. outside the box). Again, based on my vague memory that it was meant to be a short-length solution inside the box (chip-to-chip, not box-to-box).

People have got the idea that a separate clock line is somehow better than embedding the clock in a single stream - but it isn't; it is merely easier to think about. In terms of jitter due to cables and so on, it is exactly the same problem either way.

If possible the DAC should always have an internal on-chip clock and you slave the stream of data to the DAC, rather than attempting to synchronise the DAC to an external clock, which will always require clean clock regeneration based on a PLL or similar.

 

[DonH56]

People have got the idea that a separate clock line is somehow better than embedding the clock in a single stream - but it isn't; it is merely easier to think about. In terms of jitter due to cables and so on, it is exactly the same problem either way.

If possible the DAC should always have an internal on-chip clock and you slave the stream of data to the DAC, rather than attempting to synchronise the DAC to an external clock, which will always require clean clock regeneration based on a PLL or similar.

Got it, thanks. I've worked in studio setups where a master clock is essential to keep everything in synch but didn't see the need in a home. My day job includes measuring jitter in Gb systems and a separate clock causes more problems than it solves.

 

[ElNino]

People have got the idea that a separate clock line is somehow better than embedding the clock in a single stream - but it isn't; it is merely easier to think about. In terms of jitter due to cables and so on, it is exactly the same problem either way.

If possible the DAC should always have an internal on-chip clock and you slave the stream of data to the DAC, rather than attempting to synchronise the DAC to an external clock, which will always require clean clock regeneration based on a PLL or similar.

Amen to both of these points.

Plus, when the separate clock line operates at a much higher frequency than the bit clock (i.e., the master clock line in I2S), maintaining a clean separate clock transmission line is actually a harder problem than when the clock is embedded in the datastream.

 

[mansr]

Plus, when the separate clock line operates at a much higher frequency than the bit clock (i.e., the master clock line in I2S), maintaining a clean separate clock transmission line is actually a harder problem than when the clock is embedded in the datastream.

That clock isn't even part of the I2S spec. Old multi-bit DAC chips didn't need it. Modern oversampling DACs do. The required rate depends on the chip, typically 128x Fs or higher. How these external I2S sources are supposed to magically supply the correct clock for the attached DAC is a mystery.

 

[mkawa]

the new pcm15xx series and their partner adcs don't even bother with i2s and just move pcm around on board..

 

[mansr]

the new pcm15xx series and their partner adcs don't even bother with i2s and just move pcm around on board..

What do you mean by "move PCM around"? It has to be encoded somehow or other. And what PCM15xx devices are those? I can't find any such thing in a quick search.

 

[mkawa]

pcm514x and pcm422x both seem to default to left justified serial pcm. the 514x supports pcm over i2s, but if you were to implement both these chips on the same board, I think the datasheets suggest Ij serial. I may be wrong, but these are pretty popular chips as far as I can tell, and i2s is not de facto default serial io in the datasheets.

 

[mansr]

pcm514x and pcm422x both seem to default to left justified serial pcm. the 514x supports pcm over i2s, but if you were to implement both these chips on the same board, I think the datasheets suggest Ij serial. I may be wrong, but these are pretty popular chips as far as I can tell, and i2s is not de facto default serial io in the datasheets.

The only difference between LJ and I2S is that the latter delays the audio data by one bit after the LR clock transition.

 

[mkawa]

good to know. my eyes tend to glaze over looking at timing diagrams..

 

[Zog]

I am struggling to see why anyone cares about I2S these days but it is not something I have paid any attention to. I thought it was an old standard for IC connections, not cables (Inter-IC Sound, in contrast to the widely-used but not really related I2C (Inter-IC) interface) and that everyone pretty much used AES or S/PDIF instead? Don't really know, but what are its claimed advantages over AES3 or whatever? Seems like I2S, at least my very foggy memory of it, is not nearly as robust as AES for cabled interfacing (e.g. outside the box). Again, based on my vague memory that it was meant to be a short-length solution inside the box (chip-to-chip, not box-to-box).

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.