Hi, I’m running Roon ROCK (v1.3 build 234) on an Intel NUC7i5. Very stable and I much prefer it to my 2014 Mac Mini with similar specs running Roon Server.
One of the things I was really excited about moving off the Mac was I’d be able to play DSD256. My NuPrime IDA-16 DAC/Integrated will play DSD256 natively but only to DSD128 via DoP.
What I’m finding is that even though I’ve enabled Native DSD processing within the DSP Engine, I can’t choose anything greater than DSD128 under DSD Sample Rate. Roon is then downsampling native DSD256 source to DSD128 and encapsulating it via DoP. Roon is also encapsulating native DSD128 via DoP.
I have a W4S Recovery USB Reclocker (RUR) between the NUC and the DAC. I’ve removed the RUR for testing purposes and Roon behaves the same.
Any ideas on how I can native DSD processing to work? Thank you!
I’m no guru on this stuff but it looks like the DAC is reporting its capable of up to DSD128 (i.e. green). I saw the same with my NuPrime IDA8 that I used for a desktop amp.
ASIO2.1 is probably the windows Asio driver and this might not the same when using with Linux ROCK core. I have seen similar with other DACs that are 512 capable but only get to 256 with non windows endpoints.
The trick I used is to get the cheapest windows NUC style pc - I’m using an MSI Cubi celeron with windows home on it - and try that headless running Roon-Bridge
To my knowledge, Native DSD processing is not the same thing as Native DSD (instead of DoP) - someone correct me if I’m wrong. (If I’m right, I’d suggest Roon Labs to rename Native DSD processing to something else. Not that they picked the wrong name, just that the name Native has already been taken to refer to something different.)
On Linux (that includes ROCK), many USB DAC cannot reach the full DSD rate due to the Linux architecture:
Yes, different terminology is in order for “Native DSD Processing” – because it is no longer native DSD. Single bit data lacks the headroom for digital signal processing. In said processing, Roon decimates DSD to a multi bit form; only the DSD sample rate is maintained. Thus, better terminology would be something along the lines of “Native Sample Rate Processing for DSD.”
Oh, I see now. 2.1 is just the version, I should have just looked up ASIO. Disappointing to know but it makes sense at least. Thanks for that and for the suggestion as well.
I think you understand the underlying tech, but the use of “decimation” is not appropriate in this context. The word decimation, in a DSP context, refers to a process that reduces the sampling rate–something that is not happening here.
Changing from a single bit to multi-bit format in this situation is a completely lossless process–in fact, there isn’t even information loss (even in a discrete mathematical sense) until you begin processing the multi-bit form. Which of course happens immediately following that step, since the whole point of this feature is to enable processing of the signal.
It’s unfortunate that some people are getting confused by the use of the word “Native”. We have heard this feedback before, but have not been able to come up with better terminology.
My perspective is–“Native” is a marketing term, not a technical term. It’s meant to communicate that some aspect of DSD handling was done in the best way possible, and to differentiate against products that are “not native” (whatever scary thing that must imply!).
Yes, it is used to describe device drivers that are able to receive DSD streams from applications without encapsulation. It’s also the name of a music store. In both cases, it is intended to communicate that DSD is being handled “right”.
We are using it in much the same way–pairing it with the word “processing” to communicate that the processing is being handled in the best and most DSD-literate manner possible.
Technically this is accurate, but…
There are four main points to get across here:
This feature applies when playing DSD files
It avoids a conversion to PCM, which could make things sound better.
it consumes extra processing power when this is turned on
We have done this thing in the best possible way.
If people get 3-4 of those points, the text has done its job.
The goal of this text is not to give insight into what is happening under the hood–there is not enough room here to do that topic justice, and most people do not care. This is a fine line to walk.
Being too specific or pedantic can sow seeds of doubt–like maybe there is a “more native” way we could have done it that doesn’t require the “sample rate” qualifier. This is not actually the case. To someone who doesn’t understand the nuts+bolts, trying to expose the underlying implementation details more clearly in such a brief piece of text is going to create more confusion than good.
Also–a small point–the text for the name of the setting should not wrap, since it has a wrapped “fine print” paragraph underneath it. Ideally, there should be some breathing space to allow for translations, too. So the replacement string can’t be much longer than the current one.
Happy to hear any other ideas…I’d rather not have any confusion over this, and the current text has caused at least a little bit of confusion–but this isn’t the first time we’ve tried to re-write this little bit of copy. It’s not an easy one.
Whatever terminology you wish to use to make you feel warm and fuzzy inside won’t change what really matters. The end result. So far 95% of my die hard HQP and Daphile clients have changed to Roon upsampling full time with our DSD 256 DAC. And the fact that even a 2 year old I3 NUC can process these algorithims with only 30% CPU load is a great achievement. I’d suggest just using your ears to judge the upsampling. Unless of course you have a machine like the Keysight U8903B to take some ultrasonic measurements.
And BTW the industry standard terminology for what Roon calls “native processing” is “DSD Wide” or “PCM Narrow”. However those 2 terms usually stir up more arguments than anything, so the Roon team’s choice to call it native processing is likely even less confusing.
Just imagine. “Brian, why isn’t your DSD processing ‘Highest Quality’?” “Brian, can we have an option to turn on Higher Quality and maybe also Highest Quality. I mean just a switch so people who don’t care don’t have to worry.”
Thank you for the explanation, Peter.
