Is it worth spending 3 times as much for a 3% improvement?
Depends on how much money one has and where they draw the line at good-enough.
Is the cheaper one better than the more expensive one? Is it worse?
I don’t know because I did not have the occasion to try them, and to compare between them.
The cheaper one was considered as an excellent option just a few months ago, but since then the more expensive reclocker was released.
I was seriously considering buying the cheaper one at the time, but finally decided to buy a DDC instead, and keep using my Allo USBridge Signature. The DDC has a I2S reclocker.
EDIT
There’s another I2S reclocker that I did try, and it’s the Allo KALI. It was very good, but Allo does not offer as many options for audio interface electronic boards as IAN Canada does.
But as I said, I decided to go for a DDC instead.
1 Like
Three protocols that aren’t that good. I2S should never be used outside of a device over a cable; it’s a bus protocol with no error detection designed to be used inside a device. S/PDIF, a consumer version of AES, was originally designed to support CD data in the 1980’s, and has, I think, been ably superseded by the latest generations of USB Audio, which allows two-way communication between sender and receiver. However, older DACs may only be able to speak S/PDIF, and even some newer DACs apparently have some issues finding the right expertise to implement USB protocols correctly. For those DACs, S/PDIF (or AES) may be the best you can do.
In the first place, of course there’s translation and buffering going on. The signal is received over Ethernet or WiFi in packets that are buffered, then translated to the appropriate packets for I2S or S/PDIF. Yes, both of those have actual protocols that have to be formed and then interpreted on the receiving end. So tranlation, buffering, packing and unpacking, are still going on.
But even if it wasn’t – so what? I don’t get the advantage of this.
4 Likes
Engineers use things all the time for purposes for which they were not originally invented. USB is a perfect example… USB audio has an interesting history.
Of course, you have translation and buffering as you go from Ethernet to I2S. (You have a lot more going on than that) I edited my post to make that sentence clearer, though.
An I2S DAC can accept an I2S signal from a streamer and not convert, buffer or re-clock that signal. Converting, buffering and re-clocking can create artifacts.
1 Like
Having participated in protocol standards groups, I’m sure it was more boring than interesting. But what are you implying by this? In other words, so what?
Yes, and the cable that transmits the protocol that was never designed to be sent over a cable can royally screw up that signal. A DAC would be silly not to buffer, verify, and re-clock that signal.
Any mistake can create artifacts. But lots of DAC designers seem to not make mistakes in their converting, buffering, and re-clocking.
I think the upshot is that most of this outboard machinery and frippery is pointless for a properly designed DAC. One of the reasons so many Roon users are happy with a USB connection to a mass-market Raspberry Pi streamer. I’m sure that there are fragile or poorly designed DACs, however, that would profit from some of the frippery.
3 Likes
USB stands for “universal serial bus”. In other words, it was designed for anything and everything. That’s not the case with I2S, S/PDIF and AES/EBU.
3 Likes
The RPI based streamers can not clock properly the sound when they render it. Their clock is not a precision clock, and it does not work on a frequency that is an entire multiple of neither of the two basic audio frequencies: 44.1 kHz, and 48 kHz.
An I2S reclocker improves greatly their sound.
My DAC is one of those models that ASR praises, and grants with great measurements.
Still, I get a much better sound when I input through its I2S port than its USB port, either directly by a streamer with an I2S reclocker or a DDC. These devices have better word clocks than most DACs.
1 Like
USB is a serial data bus, digital audio is data? USB audio is simply a protocol for handling audio data over USB. I don’t see this as a deviation from USB’s purpose?
2 Likes
That really doesn’t matter. The frequency of the USB data transport is not the same, nor need it be the same, as the frequency of the audio samples. And the clocks are in fact pretty darn “precision”, and to much higher frequencies than are used with PCM audio. Not that that matters!
2 Likes
Pure streamers (like Pi-based ones) don’t deal with “sound” and don’t “render” anything, they just move bits from A to B. Their clock is irrelevant for D/A conversion, provided that the DAC uses a good internal clock that is not derived from or otherwise dependent on the input. That’s exactly what “async” USB does.
4 Likes
I have followed this thread since the first post and I am glad I am 61 years old. I am okay that OSHA says that my hearing loss is normal for a 61 year old. I am very satisfied that hearing loss makes my entry level Node 2i sound great to me, otherwise, my mind would explode, haha.
9 Likes
Worth repeating in all the noise that this is the only metric that really matters 
9 Likes
Yes, my point exactly. It was not designed with high end audio in mind.
That really doesn’t matter.
Maybe not to you. Everything matters. “How much” (sound quality, cost, etc.) is subjective.
1 Like
USB is a digital transport. Whether the data is audio or not, or whether the audio data is “high end” or not, has absolutely zero relevance. We don’t need to reinvent digital transports for every type of digital data we need to transmit.
1 Like
Kevin: Engineers use things all the time for purposes for which they were not originally invented.
Bill: But what are you implying by this? In other words, so what?
I2S was “originally designed” for use inside a chassis, correct. S/PDIF was a cheap compromise, designed to make use of the industry standard RCA Cable. USB 1.0 was terrible for audio. Times, and technologies, change.
If you say so. I have no interest (or time) to argue.
One can only clean up a bad signal so much. Another reason so many Roon users are happy with their USB connections is that it’s all they’ve ever had in their system. Or more accurately, the best they’ve had in their system to date.
It does matter, because this is what happens inside the streamer and the DAC:
- In the streamer, Roon Bridge renders the sound, it is converted to I2S, while clocked with the clocks of the RPI. These clocks do not work at a frequency that is an entire multiple of the two basic audio frequencies for PCM and DSD (44.1 kHz and 48 kHz)… For this reason, they can not clock the sound properly.
- The I2S sound is translated for its transfer to the DAC through the USB port.
- The DAC receives the sound that was not properly clocked. It translates it back to I2S, and clocks it. Then it processes it.
The result is a pretty good sound. But it’s not as good as if you clock the I2S sound properly from the start with a good word clock, while avoiding the translations.
Anyone who has the gear to procede with comparisons will confirm to you what I’m saying.
3 Likes
That’s so much wrong with your statement, I won’t even attempt to correct it.
2 Likes
The passage through the streamer is not a simple transfer of DATA from point A to point B.
2 Likes