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?
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.
@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.
@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.
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:
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.