m-i-c-k-e-y
Headphoneus Supremus
Yes! DX300 (as player, via USB) > U18 > R26
GUSTARD DAC-R26 Balanced Decoder R2R+1Bit Dual Native Decoding Music Bridge
- Thread starter m-i-c-k-e-y
- Start date
I'll ramble a bit about my understanding. Feel free to correct me, etc.
In principle, a DDC just converts one digital audio signal to another. I²S is what basically any DAC uses internally, so essentially every DAC has a DDC inside already.
Most external signals consist of a single bit stream that mushes everything together, e.g. the samples for both channels arrive in sequence (not in parallel), the clock is embedded as well, etc. - here's S/PDIF, for example (source):
That's 32 bits for just one channel's sample, meaning the DAC can't even do anything until it has received at least 64 bits.
My rough understanding is that the DAC wants separate streams for each channel that only contain the respective sample data, and another stream for the clock, and whatever else. That's why I²S uses HDMI or RJ45, because those connectors and cables have multiple conductors, needed for the multiple parallel signals. So it converts the external signal to what it needs internally. DACs with I²S allow you to bypass that internal conversion and replace it with something external.
But there are various ways in which a dedicated DDC might help, or even cause issues, with or without I²S. One important aspect is clocking - it's not just important that the DAC sees the correct bits (samples), it also has to change its output voltage at the right time, which is simply implied in the raw data but has to be made real somehow (the file says 44100 kHz, so the DAC has to adjust its output voltage at least every 1/44100 seconds, and the more it deviates from that ideal timing, the more likely it results in measurable and eventually audible differences).
That alone already divides digital inputs into two categories:
Asynchronous, meaning the DAC dictates the timing (most USB inputs, but in principle also DACs that have direct access to the files played, e.g. with an SD card, built-in streamer, etc.)
Synchronous, i.e. the samples come in when they come in and the DAC has to keep up - some USB inputs, S/PDIF, I²S...
Clocks can be made very accurate with a lot of effort like ovens for temperature control, radioactive isotopes, crystals, good power supplies, etc., but the further away the clock is from the device that is getting clocked, the more of that accuracy you may lose again due to interference, cable reflections due to impedance mismatches, etc.
Theoretically the best scenario is the best possible clock right inside the DAC and an asynchronous interface so that the DAC can request the samples exactly when it needs them. A synchronous source can be okay as well since short term inaccuracies can be removed by buffering (at the cost of latency) and internal reclocking, and small long term inaccuracies (say playback at 44099 or 44101 kHz, etc.) are (as far I know) inaudible.
But the best clocks are very expensive, so most DACs have room for improvement. An externally clocked signal + loss of accuracy due to distance can still be better than what the DAC can do internally, though in some cases it might not matter - if the DAC buffers the incoming signal anyway, it potentially replaces the great external timing with its own, mediocre one (but that's not the whole story, see below).
Another area is noise isolation. Irrelevant for TOSLINK (optical), but anything electrical might in principle pick up noise in addition to the raw data, possibly passing that through to the output directly, or maybe degrading the DAC's performance somehow (just guessing here, I'm not an electrical engineer). A DDC might simply be better at isolating that noise and sending the same bits along, without improving the timing, and still it sounds better because of the noise reduction - but a DDC also introduces its own noise, which may be worse than the source's, so it's not guaranteed to improve things.
And then there's switching noise, supposedly, where even with internal reclocking a poorly clocked external signal may make the DAC's receiver work harder, affecting the DAC's overall performance, so giving it a better timed signal helps with that - at least that's a narrative I've read about several times.
In some cases a DDC can also help with quirks of a DAC. For instance, the Yggdrasil mutes itself every time it loses the signal, and takes some time to be sure it has reacquired a signal before unmuting again. The MUTEC MC-3+ USB will simply send null samples when it loses the signal, so when switching between sources with identical sample rates the Yggdrasil doesn't even notice. No clicking, no muting.
With the R26 the sad thing is that it has to synthesize the clock from the internal or external reference, and with 10 MHz I assume that means it essentially has its own clock that it just synchronizes to the external signal.
If you count every 227th tick of a 10 MHz signal you get a ~44,052.9 Hz signal - far from ideal. Something inside the DAC has to make up the difference to 44,100 Hz, so there should be limits to how much an external clock can help here. I suspect there's an internal clock that gets synced to the external one, for instance by adjusting its speed so that when the internal clock has ticked 441 times the external clock has ticked 100,000 times, which means the clock synthesizer's own phase noise should supplant the external clock's (hopefully I got the terminology right).
The Denafrips approach with 45.1584 MHz and 49.152 MHz signals seems easier to make use of:
If the R26 doesn't reclock I²S signals it's not hard to imagine that a DDC providing an I²S signal could result in more of an improvement than a 10 MHz clock for the R26, at least in NOS mode... but when it upsamples the signal it needs a faster clock than what's coming in to change its output voltage often enough, and so the clock synthesizer probably comes into play again.
For S/PDIF maybe a faster clock could be extracted since the protocol's bit rate is 64x the payload's sample rate (for two channels).
Bottom line is that we have to try and compare. I'd sure like to know more about the exact inner workings of the R26, how the clock synthesizer works and how it's used, otherwise it's hard to reason what should and shouldn't result in an improvement.
In principle, a DDC just converts one digital audio signal to another. I²S is what basically any DAC uses internally, so essentially every DAC has a DDC inside already.
Most external signals consist of a single bit stream that mushes everything together, e.g. the samples for both channels arrive in sequence (not in parallel), the clock is embedded as well, etc. - here's S/PDIF, for example (source):
That's 32 bits for just one channel's sample, meaning the DAC can't even do anything until it has received at least 64 bits.
My rough understanding is that the DAC wants separate streams for each channel that only contain the respective sample data, and another stream for the clock, and whatever else. That's why I²S uses HDMI or RJ45, because those connectors and cables have multiple conductors, needed for the multiple parallel signals. So it converts the external signal to what it needs internally. DACs with I²S allow you to bypass that internal conversion and replace it with something external.
But there are various ways in which a dedicated DDC might help, or even cause issues, with or without I²S. One important aspect is clocking - it's not just important that the DAC sees the correct bits (samples), it also has to change its output voltage at the right time, which is simply implied in the raw data but has to be made real somehow (the file says 44100 kHz, so the DAC has to adjust its output voltage at least every 1/44100 seconds, and the more it deviates from that ideal timing, the more likely it results in measurable and eventually audible differences).
That alone already divides digital inputs into two categories:
Asynchronous, meaning the DAC dictates the timing (most USB inputs, but in principle also DACs that have direct access to the files played, e.g. with an SD card, built-in streamer, etc.)
Synchronous, i.e. the samples come in when they come in and the DAC has to keep up - some USB inputs, S/PDIF, I²S...
Clocks can be made very accurate with a lot of effort like ovens for temperature control, radioactive isotopes, crystals, good power supplies, etc., but the further away the clock is from the device that is getting clocked, the more of that accuracy you may lose again due to interference, cable reflections due to impedance mismatches, etc.
Theoretically the best scenario is the best possible clock right inside the DAC and an asynchronous interface so that the DAC can request the samples exactly when it needs them. A synchronous source can be okay as well since short term inaccuracies can be removed by buffering (at the cost of latency) and internal reclocking, and small long term inaccuracies (say playback at 44099 or 44101 kHz, etc.) are (as far I know) inaudible.
But the best clocks are very expensive, so most DACs have room for improvement. An externally clocked signal + loss of accuracy due to distance can still be better than what the DAC can do internally, though in some cases it might not matter - if the DAC buffers the incoming signal anyway, it potentially replaces the great external timing with its own, mediocre one (but that's not the whole story, see below).
Another area is noise isolation. Irrelevant for TOSLINK (optical), but anything electrical might in principle pick up noise in addition to the raw data, possibly passing that through to the output directly, or maybe degrading the DAC's performance somehow (just guessing here, I'm not an electrical engineer). A DDC might simply be better at isolating that noise and sending the same bits along, without improving the timing, and still it sounds better because of the noise reduction - but a DDC also introduces its own noise, which may be worse than the source's, so it's not guaranteed to improve things.
And then there's switching noise, supposedly, where even with internal reclocking a poorly clocked external signal may make the DAC's receiver work harder, affecting the DAC's overall performance, so giving it a better timed signal helps with that - at least that's a narrative I've read about several times.
In some cases a DDC can also help with quirks of a DAC. For instance, the Yggdrasil mutes itself every time it loses the signal, and takes some time to be sure it has reacquired a signal before unmuting again. The MUTEC MC-3+ USB will simply send null samples when it loses the signal, so when switching between sources with identical sample rates the Yggdrasil doesn't even notice. No clicking, no muting.
With the R26 the sad thing is that it has to synthesize the clock from the internal or external reference, and with 10 MHz I assume that means it essentially has its own clock that it just synchronizes to the external signal.
If you count every 227th tick of a 10 MHz signal you get a ~44,052.9 Hz signal - far from ideal. Something inside the DAC has to make up the difference to 44,100 Hz, so there should be limits to how much an external clock can help here. I suspect there's an internal clock that gets synced to the external one, for instance by adjusting its speed so that when the internal clock has ticked 441 times the external clock has ticked 100,000 times, which means the clock synthesizer's own phase noise should supplant the external clock's (hopefully I got the terminology right).
The Denafrips approach with 45.1584 MHz and 49.152 MHz signals seems easier to make use of:
- Count every 1024th tick of a 45.1584 MHz signal and you get 44.1 kHz
- Count every 1024th tick of a 49.152 MHz signal and you get 48 kHz
- Count every 256th tick of a 49.152 MHz signal and you get 192 kHz
- Count every 16th tick of a 45.1584 MHz signal and you get 2.8224 MHz (DSD)
If the R26 doesn't reclock I²S signals it's not hard to imagine that a DDC providing an I²S signal could result in more of an improvement than a 10 MHz clock for the R26, at least in NOS mode... but when it upsamples the signal it needs a faster clock than what's coming in to change its output voltage often enough, and so the clock synthesizer probably comes into play again.
For S/PDIF maybe a faster clock could be extracted since the protocol's bit rate is 64x the payload's sample rate (for two channels).
Bottom line is that we have to try and compare. I'd sure like to know more about the exact inner workings of the R26, how the clock synthesizer works and how it's used, otherwise it's hard to reason what should and shouldn't result in an improvement.
Last edited:
Cheers I have tried the U18 and di20he they both where a sideways step in my system. The U18 was a bit forward on certain tracks and the di a bit tame in the treble especially with the A22 I sold the di to help finance the R26
I will play with USB cables in the future I will add an external clock
rodthebod
100+ Head-Fier
Thanks Ray, I actually sussed it out last night and got the lid off whilst wondering why there were a pairs of connectors on each of the underside, I had that Homer moment!
I have to say that this is one of the best put together pieces of kit I have ever come across, the attention to detail is very impressive, the use of stainless steel screws throughout is a lovely touch and good if you adhere to the keeping everything non-ferrous following. Definitely premium feel throughout.
Now having lifted the lid, and its a lovely lid, the issue with the Lan and upgrading the firmware not working can be addressed. The card in the slot looks properly inserted and when trying to lift out, well is very secure to the point I don't want to use any more pressure for fear of breaking something. Is there a locking mechanism? Once I have the card out what's the best way to check its condition/health?
Well I had a closer look at the retaining shield and it is quite simple to release the micro SD card, it required a fingernail to gently press down on the top edge of the shield this releases the hinged retaining shield and the SD card drops down with the pins exposed. The card can then be slid out and popped into a SD card reader to re image for upgrade.
After successfully updating to the 1.21 image using the Windows USBImager 1.0.8 utility I still have no LAN or can see the R26 via the USB C.
I noticed green LED lights in the various sections on the vertical board but no LEDs by the SD card section, is this normal? Could part of the board be down......
I've got in touch with Audiophonics in France who are the suppliers, we'll see what occurs from them.
Attachments
Last edited:
comzee
500+ Head-Fier
- Joined
- Dec 8, 2010
- Posts
- 576
- Likes
- 435
So you bricked your R26 trying to firmware upgrade? That's kinda scary, makes me hesitant to want to upgrade when I get mine.
For anybody here that has firmware upgraded, what are the benefits?
Is there SQ improvements for PCM? If it's just DSD fixes, I'll pass.
Bricked? I don't think so
But if I change the SD card with one with Ropieee XL that I have now in the rpi4?
rdbogdan
Head-Fier
Not about SQ but Roon related mostly. Also check the usb driver update too, about MQA unfolding
rodthebod
100+ Head-Fier
Woah, hang on a sec, I think there is nothing wrong with the update, nothing has been bricked. I did say that my particular R26 DID NOT WORK on LAN and trying to upgrade the firmware, which are obviously tied together somehow on the PCB board, these must be broken on my box from new. It's nothing to get worried about, this stuff happens.
I did successfully upgrade the supplied 32GB SD Card using a Windows laptop with SD card adaptor using the official app. So the SD card is fine. There is something wrong with the interface which runs on the vertical board inside my particular R26. My R26 still works great with USB in and Bluetooth so it is definitely something else.
I have run Raspberry Pi front ends for many years from Allo DigiOne to Sparky USBridge and now Allo Isolator with Kali I2S. This situation, not being able to read things, happens.......... Couldn't be the SD card now I've upgraded it successfully off board, more than likely to be with the LAN interface from the factory or a dodgy connection somewhere. I'll keep you apprised of any updates, I really want this DAC to work up to its best as it sounds more and more impressive every day as it is running in. It's a new design and these things happen........
Deep down I'm thinking, why me.....
But I want it, it sounds amazing. This is the most ground breaking product I have come across in many years, I have been in the Hi-Fi industry, running my own business since 1989, retired in 2013, and this is brilliant.
Don't lose faith what this DAC - it just plays music really well.
P.S my favourite DAC is custom TDA 1541A S1 modded massively with huge PSU - I2S /USB/SPdif Input.
brianfromspace
100+ Head-Fier
Such a shame that you can’t just install Volumio on that SD card
Did some testing tonight. i2s from U18 will not do PCM-DSD upsampling with HQP. It would play and just cut out on one channel and just stop outputting audio. No issues with direct usb to pc.
Also tried lan to switch and Roon found it no problem and saw Shairpoint too.
Problem was I couldn't get Roon to play with HQP while in LAN mode. I had NAA selected in HQP output instead of Asio and Gustard.
Also tried lan to switch and Roon found it no problem and saw Shairpoint too.
Problem was I couldn't get Roon to play with HQP while in LAN mode. I had NAA selected in HQP output instead of Asio and Gustard.
rodthebod
100+ Head-Fier
Yes it would be nice to have a great interface like Volumio or Moode Audio on there but their code will be purely for Rpi architecture
shogo33
100+ Head-Fier
- Joined
- Apr 17, 2009
- Posts
- 227
- Likes
- 123
I run the ifi Zenstream with a U18 DDC and the net effect is very very nice. As @mantraone mentioned above the benefits are compounded with more of the above. The U18 by itself improved the output off my volumio based Rpi4b. Adding the Zenstream to replace the Rpi4, just showed me how important the role of the streamer is in the equation. I power my Zenstream with a topping p50.
rodthebod
100+ Head-Fier
Have you tried a really well sorted linear PSU on the RPi4 such as the Allo Shanti, this makes a world of difference to the resolution and dynamics, from experience I wouldn't use the onboard USB, I'd suggest an Allo Isolator HAT and then the Allo Kali with I2S into the DAC. This setup brings huge benefits but the PSU is very important.
Users who are viewing this thread
