Hi @spockfish, I’m planning to get raspberry pi 4 as endpoint for Roon and I will be connecting via USB to Topping DX3 Pro. Can it support native DSD without using DoP?
It should work with no issues. But why do you care if it is “native” or DoP?
There’s no actual difference in practice. DoP is unaltered DSD data. It’s just a file “shell” in PCM format so that it can be accepted by certain USB input chips that need input in that shell format.
Once it gets to the USB receiver of the DAC, the shell is discarded and the unaltered DSD is sent to the DAC chip. There’s zero audio difference between the two. It’s also an audiophile myth that “processing” of DoP requires greater computing resources. It doesn’t.
The whole “native” vs DoP is a fake marketing distinction promoted by audio companies to try and make it seem their units have some kind of superiority. “Native” DSD originally meant DSD that isn’t converted to PCM - which DoP is. The term was bastardized by audio manufacturers to make it seem as if their units are somehow superior or pure as opposed to units that work via DoP.
The only difference between the two is that your DAC will “only” do DSD 256 in DoP format, and will do DSD 512 in “native” format. This also has zero audio significance, but is a technical result of the DoP shell format. Reception of a DoP shell containing DSD 512 data requires a DAC chip that can handle PCM rates than 768, because such a PCM shell appears to the USB receiver chip of the DAC as a file it can’t handle. In fact most DAC chips at the moment do a better job reproducing DSD 256 than DSD 512, if you are going there.
2 Likes
In addition to the excellent explanation from @danny2: if you got the DAC connected to RoPieee and send me feedback I can have a look if the DAC is correctly advertiziging the necessary bits for native DSD on Linux. If that’s the case I’ll create a patch.
Thanks
I disagree that, native DSD is direct, it doesn’t go to another process of encapsulation. This mean less processing which translates to less ‘noise’. DoP required twice the amount of bandwidth just to carry a required DSD data rate and obviously it is limit to DSD256 DoP for most DACs in the market. I did have a couples of albums mastered in DSD512 from NativeDSD and I want to playback them.
I guess everyone have the right to choose what they feel comfortable with even though we have different opinions, having both native DSD and DoP are the best approach.
Thanks, Harry, I’ll getting my Raspberry Pi 4 model B soon so I will test whether native DSD actually works in my DAC😉
Again, the “processing” thing is a myth. The DSD data isn’t “processed” it’s put into a “shell” of a PCM file - the data isn’t touched. The shell is a digital container. If you transfer a glass of water from one clean glass to another clean glass is the taste changed? Is the water “processed”?
The answer to both questions is no. And this is the same type of thing.
If you actually check the amount of “processing” going on - there is no difference between the two types of DSD that can be seen when monitoring activity-because the DoP action is so trivial that you don’t see it, even when monitoring activity.
Sometimes what gets endlessly repeated at audiophile sites just isn’t true. And endless repetition of it doesn’t somehow change that.
If you want to play back your DSD 512 files as you received them, I understand why you made your request for your DAC. I’m not trying to argue with you about that - but against the idea that somehow DoP isn’t “native” DSD and is somehow inferior.
All that means is that if you had a DAC with a higher PCM playback rate for DoP, you could play the file back both ways in 512 and you’d hear zero difference between the two methods. I bet that if you try the same in an unsighted test for DSD 256, you won’t hear the difference, either.
Neither does DoP.
DoP sends 16-bit DSD words in a 24-bit frame. The first 8 bits (=1 byte) are a marker to indicate DoP encapsulation to the receiving device and is simply thrown away. The lower 16 bits are a native DSD word with no alteration. Playing back DoP is just taking the lower 16 bits and feeding it straight to the DAC. This is why DoP requires a PCM bitrate 1.5x (NOT double) the “native” DSD bitrate.
“Native DSD” is just sending two 16-bit DSD words in a single 32-bit frame. The “marker” is that a separate sub-interface (talking a USB logical interface here) is used to transmit the 32-bit frames.
Guys, @danny2 and @cwichura, I direct my first thread to Henry @spockfish regarding on native DSD support for my DAC (Support please!). I’ve no intention to turn this into a debate 'native DSD vs DoP. Thank you for all your inputs. I’ve to stop here.
I regretted I should have post my question directly to Mr Henry instead. Thank you!
Guy, it’s Harry not Henry 
3 Likes
@spockfish @wizardofoz Just got the raspberry Pi 4 model B with 4GB and tried out RoPieee. SQ improved over Aries Mini using as Roon endpoint; particularly using USB 3.0 output. A quick check RoPieee does support native DSD up to DSD512 on DX3 Pro and works great!
Just donated to RoPieee 
1 Like
Good man…I’ll be doing my usual bump into the pot again soon too
Hi, is it matter if the Roon core is on Mac Mini or other devices?
Thanks in advance!
I’m not @MusicFidelity, but can answer that it’s down to the endpoint itself, which is Ropieee in this case.
Thank you Marin. I’ll give it a try and see. I have a similar settings but with a different DAC.
Dear all, i tried and it works. The Roon Core is running on Mac Mini M1, the DAC can still upsample to DSD512 with the help of Ropieee on RPI4. Thanks!
1 Like