With the advent of upsampling in 1.3 and with a few DSD files knocking around I am tempted to make a foray into getting a DSD equipped DAC having been a previous 96/24 kinda guy. I don’t really understand how the whole driver issue works if I am using this exclusively for Roon (ie do I need drivers if the DAC is attached to my Pi3 Roonbridge ?). My core is on a 2013 iMac so im assuming that WASAPI/ASIO is irrelevant ? I am a bit ignorant of this type of detail so any “laymans terms” details and advice would be gratefully received
You don’t need to worry about drivers on Linux.
You may choose to worry about whether or not the device supports “Native DSD” playback on Linux. This can be a complicated topic…
There are also a (very small) number of DACs that have some sort of limitation that makes them not work with Linux, or not work completely with Linux. When it comes to this stuff, the least painful option is to simply avoid DACs with these kinds of problems.
You are correct, you don’t need to worry about WASAPI/ASIO at all. That’s Windows stuff.
Probably the best thing to do would be to post a couple of the DAC’s you’re considering and see who has experience with them and see if anyone is aware of specific problems or limitations. For the most part, things should just work, but it’s always nice to have some sense that other people are in a good situation with something before spending the money.
1 Like
Hi Paul,
If you are looking at Native DSD rather than DoP then DietPi has just been patched to implement the fix in ALSA for the “popping” problem:
I’ve found in Mac OS that the DSD support seems to be one step down on the same DAC running under windows with ASIO drivers. I.e. A DAC that in Mac OS I get only DSD128 whereas in Windows I get DSD256
Not all DACs but certainly some.
Could someone enlighten me to the benefit of native DSD vs DoP?
Not being flip, but very curious. There’s a ton of buzz surrounding this, but I honestly can’t understand the benefit. DoP is still DSD. It’s just packaged in an envelope much in the same way that RAAT data is packaged in a TCP/IP envelope.
Thanks for the advice. I don’t think I am bothered about Native DSD. I am happy with DoP as a form of transfer. At this stage it would be low key dabbling and would probably be a relatively cost dabble.
Andrew I think it might be like that Shakespeare play - Much Ado about Nothing.
Where the DoP packets go directly to a separate DSD stage and are never dealt with as PCM (eg: Holo Audio Spring) then I understand that there is no real technical distinction between DoP and native DSD. The DoP is just a decimated DSD stream. I haven’t made a careful comparison of the two on the Spring but I couldn’t hear a distinctive difference when swapping from one to the other (the popping issue took prominence !).
Where, however, the DAC receiving the DoP packets processes them through a PCM stage before converting them again to DSD then there could well be an audible difference between the two.