Hoping for a little clarity with respect to native DSD output capability of the ROCK/NUC over USB. I’ve searched and read quite a bit but not quite seeing, or grasping, the detail. It seems like it’s dependent on the DAC you want to output to in that it needs to be known and supported by the Linux kernel on Rock.
If this is the case, is there a current list of supported DAC somewhere?
At what rates can DSD be output: 64/128/256/512 etc?
Is this also the case for native DSD output via HDMI?
Personally interested in connecting a Bryston BDA-3.14, which I’m told is a BDA-3 with a Pi bolted in (I have no interest in the Pi, I just use the DAC). But also curious about other DACs as I may move to something with better support.
Roon Ready DAC? I mean, Roon Ready Streamer, sure, but I’ve never heard of a Roon Ready DAC unless it’s part of Streamer/DAC combination…
And if by Roon Ready DAC you mean DACs that are known and baked into the Roon kernel, then why would I Google that? This is the point of my post - surely the Roon organization would know what DACs they have supported for direct connection to a Roon Server (and ROCK) - in which case, where can I find that list and details?
Your second comment is on the money though and it’s what I’m asking: IF my DAC (or the DAC in your receiver) is connected directly to ROCK via USB (or HDMI in your case) and my DAC supports native DSD over USB/HDMI - should it native streaming “just work” (apparently yours does not) or does it have to specifically be on a “supported by the kernel” list in order for it to be possible?
I’m trying to avoid purchasing parts for, and building, a ROCK if it won’t send native DSD to my DAC. And if it won’t, what DAC WILL it send native DSD to? Note that I know DoP surely will work and DoP is unaltered DSD inside a PCM wrapper. That’s not the point though, which is why I’m asking about sending DSD natively.
ROCK has better support for DSD than most Linux kernels. But it is probably best if you tell us what you are interested in and maybe we can tell you if they work.
There is only a few Roon Ready DACs that can connect over the network, Mytech Brooklyn Bridge , Merging NDAC, Matrix Audio have one I think to. The majority and I think what he means is Roon tested. But this does not mean full native DSD is possible, this is down to the DAC and if drivers have been released into the Linux kernel. Most DAC manufacturers are pretty rubbish at this. If they are not Roon will fall back to standard USB Audio 2 drivers which means no native DSD just DoP.
Native DSD and Linux is very spotty and needs to be investigated on a case by case basis if that is your intended goal. I always suggest contacting the tech support of the DAC Manufacturer and just ask, can I do native dsd via USB with linux?
If they say yes, then you verify that the linux device has been patched for that DAC.
If you read the Bryston manual it only mentions native DSD in the context of using the ASIO driver in Windows. So, I’d contact them to find out for sure.
Perhaps I was a bit too wordy in my original post. I did try and include all the information, so perhaps it ended up unclear.
I’m considering building a NUC based ROCK and connecting it directly to my DAC via USB. The ROCK would have a wired ethernet connection, the DAC would not. The music files are on a NAS also connected to the LAN. Music control would happen via a tablet. The question is, what determines whether or not ROCK can output native DSD in this situation?
The DAC in question is a Bryston BDA-3.14. Yes, this is a streamer/DAC that is not yet certified with Roon as a player. However I’m not using it as a player over a network, it’s only being used as a DAC. The published specs show it is capable of accepting native DSD.
What would prevent this from working?
Henry says ROCK has better support for DSD than most Linux kernels.
Daniel says ask the DAC manufacturer if their DAC can do DSD for linux and if yes make sure the kernel has been patched for that device (which kernel on which device?).
Gypsy talks about drivers in the Linux kernel (in the DAC or in ROCK?).
Somehow I’m not getting clarity on what driver needs to be in which kernel on which device. Does ROCK query the DAC to see if the DAC says, “yeah, I do native DSD” - and is this response the job of the driver inside the Linux kernel of the DAC? In which case this has nothing at all to do with Rock’s capability, it just asks the question. Or not?
Daniel may have revealed a “bait and switch” from Bryston though with respect to the Windows driver. If this is true current information and I’ve got this right, it would mean a Windows system with that ASIO connected to this DAC would likely get that reply back from the DAC that says “yeah I can do native DSD”. But now we’re talking about the driver not on the DAC but the player… Can anyone understand that I’m utterly confused?
Please check our Roon Ready player product line with analog outputs, e.g. Lumin T2 that supports DSD512.
For native DSD over USB from Linux, it has to be supported by the kernel.
For native DSD over HDMI from Linux, please forget it.
You will need to ask around here. “DoP surely will work” is not quite correct - with many DSD256 DAC, DSD256 DoP is not possible, so we do need native DSD.
To describe this simplistically, Linux kernel has a table of known USB DAC that can support native DSD. If it happens to be using XMOS chip with known XMOS DAC VID with a modern XMOS firmware, then there’s good chance native DSD will work. But making it into the list does not guarantee it will work. From time to time I make special firmware adding specific VID PID for customers to see if native DSD will work with their DAC (most recent examples include Bricasti and McIntosh DA2).
However, this is necessary but not sufficient - there are other things that need to work. And I’ve seen incorrect entries in some versions / distributions / of the Linux kernel. Ultimately you need some sort of confirmation from other users to really know.
I have a T2. No Roon or Lumin shenanigans around upsampling/transcoding etc. Sounds just amazing. Not using a Linux core - why complicate things? Mac mini works great.
In my previous add to your post I referenced a online search for Roon Ready Dac. I have an OPPO 205 that is a Roon Ready Dac/Player connected to my Nuc/Rock via USB and Ethernet and it does play Native DSD files via the USB connection. I found out the OPPO I had was Roon Ready but had no idea what that meant. That is one of the things that originally led me to Roon.
Not sure of the exact wording to describe Roon Ready but I believe it indicates that Roon Network code (RAAT) is preinstalled in the device for communication.
The online search for Roon Ready Dac/Streamers will return lots of references including a link to the Roon Labs: Partners page.
Lumin make great gear that is out of my league in terms of price. I’m not looking for new components.
See, that’s the thing - WHAT KERNEL? The one on the ROCK/NUC (Roon core) or the one on the DAC that is connected via USB? I assume you mean the kernel in Roon and clearly it IS capable, but I understand that it depends on the DAC. This is the whole entire point of my question: Will ROCK do native DSD when connected to a Bryston BDA3/3.14 via USB?
Yeah, this was mild small curiosity. My Oppo 104 does send native DSD64 to the Bryston DAC over HDMI with zero issue though…
Well… yeah, that’s what I’m doing… - asking around here…
DoP does work fine with the DAC (though not at 256), but I’m only concerned with native DSD transport.
OK, NOW we’re getting somewhere. This gives me insight into the communication between the player and the DAC. And I see how it’s dependent on both “ends”. I was hoping that it was more defined than that, but I get it now.
Still, the question remains which no one has answered: Will ROCK do native DSD when connected to a Bryston BDA3/3.14 via USB? Or put another way: When a Bryston BDA3/3.14 is connected to a ROCK directly via USB is it possible to use native DSD transport? It will take someone with this setup to answer or I will have to buy/build to answer it, apparently.
His point is that if you use a Roon Ready player, you do not need to worry about DAC-specific USB native DSD support issue of Linux kernel in ROCK. That is even true if you use a Mac Mini as Roon Core, especially considering Mac does not support USB native DSD (with one or two exceptions.)
Sure, the Partners Page is one of the first places I looked. But it lists no standalone DACs. It lists pure streamers (transports) and players (DAC/streamer combinations) - both of which have network ports (and/or WiFi). Although I’m far from an expert, the term Roon Ready is as you say: related to RAAT code on the device for communicating via the network. But this is unrelated to transport communication between a Roon core and a directly USB attached DAC - and this is the heart of my question.
Yep, I’m aware of that possibility. I’m also aware that there are some glitches related to that configuration and some patches that may or may not successfully address the issues. But that means an addition piece of gear and another network drop (I don’t do wireless, it’s evil incarnate). I was hoping to get Roon Core off of my desktop PC and onto a NUC/ROCK in a fanless case right in my audio rack. One piece of gear to run Core and be the endpoint.
Honestly, it’s very kind of you to have done that research on my behalf. Thank you. However I have read that article and have had the BDA-3.14 in my system for 6 months, so I’m quite familiar with the aspect that they are discussing in that review. They are talking about its streaming capability through the internal Pi. Absolutely true that the internal Pi will not “do” DSD from Roon. But, as I’ve stated multiple times in this thread I’m using my BDA-3.14 as a DAC only, I’m NOT using the streamer. And the documentation is clear that it WILL accept DSD via its USB port (and DSD64-only via its HDMI input).
Don’t know the internal Pi’s version and how it’s connected to the rest of the Bryston’s internals, but popping the lid may clarify things, and with a tinkering spirit, it could well be possible to insert another SD-card flashed with Ropieee into the internal Pi…
- asking around here…