• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

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

GPx86

Member
Joined
May 24, 2018
Messages
37
Likes
51
You might notice that I made no claims of my personal belief for the topic of experiment whatsoever. Only that the experiment and the data that came out of it are flawed. But maybe I'm on the wrong forum. :rolleyes:
 
D

Deleted member 65

Guest
The LR inversion has no effect whatsoever on jitter, so those measurements are still valid. This error does, however, highlight another aspect of these devices. Due to lack of standardisation, slight incompatibilities can easily creep up with no obvious malfunction yet objectively degrade the performance.

Still, Gpx has a point. The review had the wrong input parameters even though the outcome/conclusion may have been the same.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,560
Location
Seattle Area
Still, Gpx has a point. The review had the wrong input parameters even though the outcome/conclusion may have been the same.
Feedback was provided, I made correction, and re-ran the test. That is the nature of what do. An edit was put in the review reflecting the same:

EDIT: Setting mode switch 6 to on fixed the phase delay.

Comparison of I2s on Gustard U12 didn't have this issue anyway so those results hold and no changes were necessary for them.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,560
Location
Seattle Area
What firmware did you use on the SU-1? The USA distributor, Kitsune Hifi, has an image on their website that says the Gustard I2S requires V202 on the SU-1. Did you confirm you have the correct firmware?
I made the change to dip switches as documented and it worked. So I assume it had up to date firmware.

In general, I do NOT change firmware on devices unless it is absolutely necessary. Updating firmware can brick products and at any rate, will evaluate the device differently than how the owner is using. The owner may also not want a new firmware and backing out the same is not always possible.

If a manufacture or other owner thinks results will be different, they can send me theirs. If it is not worth it to them, then that is that.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,560
Location
Seattle Area
You might notice that I made no claims of my personal belief for the topic of experiment whatsoever. Only that the experiment and the data that came out of it are flawed. But maybe I'm on the wrong forum. :rolleyes:
How is testing the Gustard U12 with Gustard DAC-X26 is flawed when comparing S/PDIF to IIS?
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,560
Location
Seattle Area
I'm concerned that you did not ensure you had proper settings on your equipment before taking these measurements. Instead, you made presumptions against the notion that I2S could be beneficial in any way, and you instituted confirmation bias by allowing your setup to dictate and support your own presumptions.
Confirmation bias? How do you induce that into an analyzer? I have my predictions but data always speaks. I can't predict how actual implementations work and hence the reason I measure whereas many would just laugh and not bother.

I have tested differences between USB cables, speaker cables, reclockers, power supplies, etc. In all of these cases I put any personal opinion aside and ran the tests with straight face. It is very disappointing to read such remarks otherwise.

You have some data that shows IIS is better, let's see it. Just accusing me of confirmation bias in an improper manner doesn't do anything.
 
D

Deleted member 65

Guest
Feedback was provided, I made correction, and re-ran the test. That is the nature of what do. An edit was put in the review reflecting the same:



Comparison of I2s on Gustard U12 didn't have this issue anyway so those results hold and no changes were necessary for them.

Oh well, I don't want to argue much, but you do write on page one "Since the U12 works better, ..." I don't see this.
 

GPx86

Member
Joined
May 24, 2018
Messages
37
Likes
51
If you reran the test, I still see the data that was taken with incorrect parameters on the Singxer SU-1. The note says that changing the parameter fixed the phase problem, but there is no data to support this. You show only the data taken with incorrect parameters, and still your comments and conclusion based on the wrong parameters.

According to the manufacturer's specs, you changed only 1 of the 3 parameters required to make the system function as designed. If you're unwilling or unable to use a system properly, what's the point of taking any data at all? It's been mentioned numerous times here that there is no standard for I2S when connecting components externally. It is well documented that the Singxer SU-1 has settings that does make it compatible with numerous devices using I2S. If you're going to attempt to prove something, you need to actually use the device under test properly.

You ask Paul McGowan to not spread misinformation about I2S, yet you make a conclusion based on your unwillingness to research a product and use it as it was designed. You are the test engineer and operator in this case. It is up to you to setup the test conditions and ensure impartial results. There is no impartiality in this result.
 

mshenay

Active Member
Joined
Feb 9, 2018
Messages
177
Likes
206
If you want to use lay assumptions, think of how S/PDIF is decades old and by now, folks have figured out pretty well how to extract the clock out of it and deliver excellent performance. Such is the case here. S/PDIF has universal compatibility to boot which I²S does not have.

This, I like SPDIF for this reason. I find it well implemented in a LOT of devices and strongly prefer it over USB. Not that it's better than USB as in many instances it's marginally "different" but the sheer compatibility and consistency are why I default fo S/PIDF

Plus I've had a few very nasty USB experiences over the years and even more getting USB Drivers to work on a variety of window's based systems. So I'd rather just enjoy the relative simplicity and consistent performance [imo ymmv] that is S/PDIF as a digital interface
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,560
Location
Seattle Area
According to the manufacturer's specs, you changed only 1 of the 3 parameters required to make the system function as designed. If you're unwilling or unable to use a system properly, what's the point of taking any data at all?
I flipped the three dip switches as instructed in the manual. Two of them made no difference so I didn't mention them in the post.

The "system functioned" properly after the change. Phase shift in one channel went away and everything else stayed the same. I didn't see the point of spending time documenting and posting it. Now, if you want to question my honesty or ability, why stop there? Maybe I didn't even test IIS and post fake measurements?

Anyone who is familiar with my work here, knows that I am not about posting a mountain of measurements. As it is, I lose audience quickly. If there is no value in a new graph, I make the decision to not post it. In this case, there was a phase shift, constructive advice was given unlike your post, and I immediately acted on it and the issue went away. Now you keep complaining about something that was addressed, without pointing out how the data is invalid.

You ask Paul McGowan to not spread misinformation about I2S, yet you make a conclusion based on your unwillingness to research a product and use it as it was designed. You are the test engineer and operator in this case. It is up to you to setup the test conditions and ensure impartial results. There is no impartiality in this result.
Unlike Paul, per above, I took advice and immediately changed and updated the results. Paul has done no such thing.

As to "researching," if that is what is required to make IIS work, that is another thing against it. S/PDIF is plug-and-play and no such USB to S/PDIF requires any research. That the SU-1 and IIS needed this, was brought up in the post in how it showed incompatibility. In that sense, this was a good outcome. Now maybe you can go to Paul's forum, point him to my measurements, and ask him where the evidence of "considerably better sound" is hidden. Would great to see how you get treated there.
 

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
Could someone clarify how I2S is being used as an external interface? Earlier I was assuming that the audio source was acting as master, i.e. that it supplied the data and the clock. But am I wrong in this? Is it, in fact, the DAC that supplies the clock, and the source is slaved to that, effectively sending data out at the rate requested by the DAC? In which case, I would be wrong in saying that it is no better than S/PDIF.
 

sonci

Active Member
Joined
Feb 18, 2018
Messages
233
Likes
112
Here are the results with GPLL bypassed:

View attachment 23913

While not audible either way, jitter is worse with S/PDIF when you turn off GPLL.
I think this should go in the conclusions, not everyone reads all the posts. This seems really important especially for those using old dacs with no GPLL, and can diy I2S.
 

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
I have an interesting snippet from one of the PS audio forums.

1553332294453.png


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

Attachments

  • 1553332125612.png
    1553332125612.png
    78.8 KB · Views: 149

anmpr1

Major Contributor
Forum Donor
Joined
Oct 11, 2018
Messages
3,723
Likes
6,407
I have an interesting snippet from one of the PS audio forums...

I casually dropped by in order to review some of the PS forums. In the 'digital' section, people are seriously debating whether they need to 'burn in' their PS Audio device before it starts to sound better. Most say yes, some are not sure. Some think the sound goes from good to bad to better during the burn in period. 100 to 300 hours appears to be the sweet spot consensus. Type of interconnect cables used is a big factor, too. Must get this right in order to obtain electrical synergy between devices.

Disinformation? You're asking Paul McG to stop? Really? This sort of thing tells you all you need to know about the mindset of Paul's customers, and likely all you need to know about Paul's own mindset, when he's bringing gear to market. Does he really believe it, or is it just marketing? I have my own opinion, but can't write any more. I've misplaced my Hosemonster Vallhalla series directional Ethernet cables...the ones with the upgraded Loge Magic Fire (tm) termination plugs. The pace on my NAS seems a bit off, so I need to make a few changes...
 

JJB70

Major Contributor
Forum Donor
Joined
Aug 17, 2018
Messages
2,905
Likes
6,148
Location
Singapore
Thi may get me drummed off the forum in disgrace, but I can't say I've ever noticed any difference when switching between the various digital interfaces, admittedly I never did anything as scientific as an level matched double blind test but my non-scientific conclusion is that it is one of those things where there may be measurable differences but in terms of audibility it is basically a sterile argument in my view. Certainly compared to the audible differences associated with speakers, speaker placement, room correction, headphones etc the digital interface is not what I'd see as a part of the chain to be investing much effort into.
 

anmpr1

Major Contributor
Forum Donor
Joined
Oct 11, 2018
Messages
3,723
Likes
6,407
Thi may get me drummed off the forum in disgrace, but I can't say I've ever noticed any difference when switching between the various digital interfaces.

The thing is, even if it's all aural chimera, you probably want to spend dollars wisely. Support good engineering at a particular price point. What gets me are companies selling overpriced junk that offers no value at all, against lesser priced competition. This doesn't mean that high priced gear has no reason for existence. There are a lot of reasons one might want to buy an expensive solid state amp: quality of construction, dealer and manufacturer support, pride of ownership, visual aesthetics (backlit blue meters)... etc.

Loudspeakers are really the only modern day component where anyone can reliably tell differences. Loudspeakers are really the last remaining subjective component. Coupled to your listening room, which could make the same loudspeaker sound different. Of course, the recording itself makes a huge difference, but that seems to be a given. Possibly, just possibly, amplifiers, if the device is tweaky to begin with, and horribly mismatched to speakers--say, an SET amp connected to a crazy low impedance speaker, one that requires high current availability. Then, for old timers like me, phono carts (but probably not phono stages) and turntable/arm combos could make a difference. Cassettes and open reel decks. But who cares about them? Anything mechanical, producing lots of distortion. But then we are back to loudspeakers.
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
4,685
Likes
10,700
Location
Hampshire
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.
That's just his way of saying they use an ASRC, like in the ESS chips. He apparently avoids using standard terminology in order to appear clever and make the product seem special when it's really not doing anything unusual.
 

Zog

Active Member
Joined
Mar 13, 2019
Messages
255
Likes
290
So what do you do? Why can't we just introduce another ultra low jitter master clock at the receiver end. You can do if you want but you still need the PLL. The trouble is that even if you use another of the same ultra low jitter oscillator used in your CD player the two wont run at exactly the same speed. They aren't synchronised, they are close, but not identical. This is where the asynchronous sample rate converter (ASRC) comes into play, in other words the 'jitter removal' part of what's included in ESS DACs. These take the bit clock, LR clock and data line that is generated by your S/PDIF receiver and process it. In doing so they (in basic terms) essentially generate a software based version of what the analogue waveform would look like for the signal input into it. You then attach your ultra low jitter master clock to the output side of the ASRC. The output side then samples the software waveform and creates a new set of data. This is then output from the ASRC, you get a new bit clock, LR clock and data line timed to a new master clock of ultra low jitter and Santa comes down your chimney. Jitter be gone. So it's perfect right? No. First of all it's not bit perfect because the output side of the ASRC generated a brand new set of samples. Second is that (apparently) the jitter present on the input of the ASRC is simply shifted to the output in a different form. ASRCs weren't actually invented to remove jitter, they were invented in order for two systems using dissimilar sampling frequencies to interface with one another. You might have an ADC and DSP that you want to link together. The obvious way to do this is to run one as a master and the other as a slave, but the world happens and they might both be masters, or both in entirely different boxes from one another, so the ASRC is used to allow them to talk to one another. It just so happens that ASRCs also attenuate jitter so they found themselves being incorporated inside DACs.

A very obvious way to circumvent all these jitter issues is to simply remove the S/PDIF receiver and transmit the I2S stream directly from box 1 to box 2. This isn't simple (like S/PDIF), for a number of reasons, but if you do it correctly then it does work very well. We can see this in the measurements above with the ESS chips jitter reduction switched off. The direct I2S stream is much cleaner. It should also be bit perfect because the on-board ASRC has been disabled. I've done I2S over network cables myself using LVDS no problems there and you can also get transformer based LVDS systems that offer isolation between one end and the other, a bit like TOSLINK optical cable only not using the S/PDIF standard.

Thank you very much 5th element for an in-depth and considered reply. I have read through it twice and will do again.
 

captain paranoia

Active Member
Joined
Feb 9, 2018
Messages
293
Likes
218
A comparison of S/PDIF to I2S is just fine, but a comparison to USB doesn't really make much sense. S/PDIF and I2S are both protocols for transmitting audio, USB is not.

USB can be, and is, used to carry audio protocols. It's that 'Universal' bit of the name...

Most importantly, USB, being a bidirectional protocol, allows the use of a destination-sourced clocking scheme, where the destination device requests data from the source. This allows the DAC clock to be master timing element, rather than a slave. No clock recovery is required at the DAC end; it is replaced by a FIFO buffer system and flow control protocol. This works in a similar manner to an integrated CD player, where the DAC clock is system timing master, and the CD read mechanism is slaved to this clock.

[edit: I confess to doing a [TL;DR;] on the remainder of your post, which is a shame, because I now see that it makes a similar point about DAC master clocking. Cosmic has addressed your comment about SPDIF not carrying a bit clock; it does, with biphase encoding)]

Decent clock recovery can mitigate the problems of the DAC being a timing slave in SPDIF or I2S protocols; indeed, my first thought on reading Amir's OP was whether both SPDIF and I2S inputs were going through the same clock recovery process, regardless of the clock source. A later post, showing the result of turning off the 'GPLL' suggests that is inded the case, and we then see the difference between the performance of the separate clock of IS and the embedded clock of SPDIF.

I2S has the potential to provide a better clock if the destination DAC does a poor job of clock recovery. That's probably the real takeaway message of these tests, and is no surprise to me at all.
 
Last edited:
Top Bottom