I have a Nucleus + on the way along with a Chord Hugo TT2. Both of which claim DSD 512 support (though I know the Chord converts to PCM). I have been running Roon on my iMac Pro to get used to the software and was confused by Signal Path information:
Is the DSD 512 converted to PCM 352 because of a hardware limitation? I can see the other downstream conversions could be due to hardware limitations. I just want to be sure the Nucleus + will be passing full bitrate DSD 512 over the USB cable to the Hugo TT2. Am I correct?
In the āDevice Setupā screen for the Hugo TT 2 zone, ensure that
A) āExclusive Modeā is enabled.
B) āDSD Playback Strategyā is set to āDSD over PCMā.
The Chord Hugo TT 2 will only play DSD512 when connected to a Windows PC running the ASIO driver. Playback will be limited to DSD256 maximum on macOS and Nucleus (Linux).
This IS NOT what I have been told. I specifically purchased the Nucleus + for the ability to play DSD 512 with the Chord Hugo TT2. If this is correct, I will send both the Chord and Nucleus back to the dealership. They claimed they checked with Roon and it was guaranteed to play as I describe.
BTW - this is not the question I asked, but this is MUCH MORE important.
The conversion to PCM 352 happens regardless of your hardware, it is the next two steps that deal with hardware limitations. In simple terms I think this is what is happening.
44.1kHz 512bit ā” 352.8kHz 64bit, but the MacBook has a maximum sample rate of 96kHz 24bit, so there is a conversion to 88.1kHz 24bit.
@Martin_Webster - thank you. My iMac Pro probably has similar hardware limitations in this area as the MacBook. That said, your post made me go back and (re)do the math. 352.8kHz at 64 bits - if that is what it is, and one can infer that from the Bit Depth Conversions further down the path from 64bit Float to 24bit is abut 22Mhz., which is what one would expect from a DSD 512 stream.
Keep.in mind that Mac OS will not do native DSD rates. Windows PC with the appropriate driver is your best bet, no matter what hardware you get, if high rate DSD is your goal.
@Rugby thanks for the note, but that is not what I am asking about. It is also a bit frustrating to get told different things by Roon. I have been assured that in spite of the lack of a driver for Linux (and I know the Nucleus + is Linux based) it will output DSD 512 over the USB. Whether that is Native or DoP (which would be an even higher data rate due to the PCM envelope), is not so important as long as it works.
At this point, I hope that @danny would weigh-in. The question is as I put it. Will the Nucleus + output full data rate DSD 512 to a Chord TT2? I have been told by the dealer - at least twice, he said it would.
I have no DSD512 music, however using the sample rate conversion in Roon I can convert to DSD512 and output that directly to my DAC which natively supports DSD up to 512 (or PCM up to 768K/32bit).
This is using Roon on ROCK (on an intel NUC i7) server outputting to a directly connected USB DAC. However, if I plug the same DAC into my macbookpro instead, then I can only select up to DSD256.
Also just noticed on the mac the audio pipeline indicates DSD over PCM, whereas on ROCK it indicates DSD512.
This suggests you should plug you DAC directly into the Nucleus assuming it is basically similar to a ROCK based NUC setup.
Unless you have the same DAC, that it works for you doesnt help the OP. Native DSD in Linux is on a case by case, or, DAC by DAC basis. Each Linux version needs to be patched, if even possible, for each specific DAC. Your DAC might not work the same way one different Linux.
All in all very confusing and we need to do a lot of research before buying. Which is why I always suggest Windows because that will work everytime by loading the drivers.
OK - that I didnāt know - thanks. I must have always been lucky on Linux then as everything has just worked
A very quick search suggest no chord DACs had native DSD driver support as of Q4 2018 - so I guess probably windows driver only. TBH - DAC manufacturers should really detail stuff like this. It is not really helpful of them to say ādriverless for mac and linuxā in more or less the same sentence as DSD512 is mentioned. They really should be explicit about this kind of thing with a link onto their web site they keep up to date. Same with everyone else in this space as well.
I thought that was the case. I have however read conflicting reports of this.
@Adam_Goodfellow - Thank you. Yes - my plan is to directly connect the Nucleus + to the Chord Hugo TT2 via USB. Your math also makes sense. That is if you are not doing Native and do DoP you will be at higher rates. If you do the math, that puts you in about the ballpark of Native DSD 512. I suspect the difference if encapsulation overhead.
At this time, probably not. I know this isnāt what you want to hear, but hopefully this will explain what the technical challenge isā¦
As others have mentioned above, there are two ways to send DSD over USB. The first is via DSD over PCM, or āDoPā. (This is not conversion to PCM, itās hijacking PCM as a bitstream transport for the raw DSD stream.) The second is ānativeā DSD. With the overhead that DoP has, you are restricted to DSD256 max over USB. To achieve higher rates, you need ānative DSDā support. This is true of ALL audio USB devices; itās not unique to the Chord or Nucleus.
Officially, Chord only supports native DSD on Windows, which rules out the Nucleus(+) as it is Linux-based. However, Linux does support a number of native DSD devices over USB (at least for devices build using an XMOS USB chipset). For this to work, their USB vendorid/productid pair must be included in the bindings list for the native DSD driver in Linux. I know Roon has updated this from time to time for ROCK, so there are likely some devices supported by Nucleus. But it sounds like the Chord is not currently one of them, based on other responses here.
You could check with the RoPieee and DietPi folks to see if they have added native DSD support for the Chord. They tend to be much more ābleeding edgeā when it comes to updating their kernels by hand to include recognition of native DSD supporting USB devices. Using a RaspberryPi as your endpoint connecting to the Chord isnāt really a bad idea, either. Lets you have it as a zone and then put the Nucleus in your computer closet.
@Rugby- DoP should work as long as the DAC can process at data rates sufficiently high to cover the difference. In another thread, we did the calculation and it is about 22 Mhz. for DSD 512 with DoP. An . increasing number of devices now are supporting 768/32 PCM.
The thing that is so frustrating in all this is the lack of clarity by the vendors. The only place where I an 100% that I can get DSD 512 end to end us with the Auralic G1/G2 Vega and Aries products.
I think this is not exactly correct - though I could be wrong. How I would say it is that to use DoP, the system has to be capable of processing at higher data rates to deal with the PCM wrapper information around the DSD data. In practice, I think most of the time you are correct. See my note below about devices supporting PCM at 768k data rates. If this is true, I am pretty sure the DAVE from Chord would work. I am trying to get an answer on that.
Am I understanding correctly that you are suggesting the path be:
Nucleus +
Something like RoPieee acting as an endpoint
Output from the RoPieee to the DAC
If so, it seems to me that there would be some loss of SQ. But thank you for the idea.
Feel free to ignore this post as I have nothing to add, but only a question. ,
Let me state that I too used to either buy DSD format or have Roon convert to DSD format. The DAC I have now upsamples to DSD1024, although Iāve found that I prefer 702/768.
So, this isnāt an outright criticism, but why the fixation on DSD512 particularly when using the TT?
BTW - An acceptable answer is, āJust becauseā.
