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.
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:Still, Gpx has a point. The review had the wrong input parameters even though the outcome/conclusion may have been the same.
EDIT: Setting mode switch 6 to on fixed the phase delay.
I made the change to dip switches as documented and it worked. So I assume it had up to date firmware.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?
How is testing the Gustard U12 with Gustard DAC-X26 is flawed when comparing S/PDIF to IIS?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.
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'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.
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.
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.
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.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?
Unlike Paul, per above, I took advice and immediately changed and updated the results. Paul has done no such thing.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.
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.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 have an interesting snippet from one of the PS audio forums...
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.
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.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.
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.
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.