Thank you @danny for you detailed recommendation.
Will the LINUX “super trimmed Roon OS” be available for end users ?
I’d love to release it to end users, but we have three major issues:
- we don’t want to have to deal with support for every wifi chip out there… this is a nightmare to get right
- we can’t ship codecs for MP3/AAC – it would make our “free” OS image something we’d have to charge for, as we’d be distributing patented code.
- we are unsure how to handle updates after users tweak their systems. our current update system blows away all changes by rewriting the rootfs.
The OS comes with a web configuration for IP address stuff, and some utility functions for factory reset, reinstalling the OS, reinstalling the Roon software, and it comes with a ~200megabyte image meant to be written to a USB stick that will debrick any system (it repartitions and hard writes the rootfs and the roonserver partitions). It really is what many people want… we just don’t know how to solve the above 3 issues.
[quote=“danny, post:23, topic:10695”]
… we just don’t know how to solve the above 3 issues
[/quote] I hope you will. In the meantime i will try with some vanilla LINUX. Thank you again for your insights.
Hi Danny,
Point 1) true for wifi, but I think that many people run the RoonServer on a wired machine (interesting to figure this one out actually).
Point 2) couldn’t this just be a simple note: “RoonOS is not suited for handling MP3/AAC collections”?
Point 3) well, for now I could live with this. Later on it would be cool if the configuration would be stored in the cloud or something like that.
Regards,
sure, but the next feature request will be wifi support 
better to get this planned in advance
no, since TIDAL streams AAC sometimes, and there are always MP3 radio streams. Part of the Roon experience is that everything just works, regardless of how you installed.
Yah, but to solve the codecs thing, would be a user change, and this would blow it away.
Given no compromise, any suggestions on what people would want to do here would be interesting.
Yeah. Hmm… I’m getting the picture here, and why you’re not releasing RoonOS in any way for now. But the idea of Roon having it’s own ‘distribution’ so to speak that is minimalistic and ready to rock wrt RoonServer sounds like a very interesting idea.
It would help customers that are maybe reluctant to run Linux themselves.
So I’m still wondering and thinking… wouldn’t some users that want something very easy for setting up their server pay a reasonable amount?
Ok, I’m not going to bother you any longer with this 
I’ve been looking at this same config. Running the INTEL NUC with SDD (128GB) and NAS for music files. This will allow me to run a Roon Core in my listening room directly hooked up to my DAC via USB and eliminate a Roon Bridge, eliminating dependency on yet another device and network. Any suggestions/concerns with this configuration?
There’s a school thinking that increased activity on the device running Roon Server leads to an electrically noisier environment, which could in turn pollute the feed from the device to the DAC. Roon is designed so that all heavy lifting is done at the server end of the equation and Roon Bridge can run on a low power device that is essentially just about idling as it passes audio through to your DAC. In essence it’s therefore preferable to separate Roon Server from the endpoint by utilising a suitable device to serve as Roon Bridge.
Thanks Evan. So, if I buy two of the identical devices (Intel NUC, as above (SSD, fanless)) and one runs Core and the other Bridge, you’re saying that the sound from the Bridge alone would have a lower noise floor than a single box running both Core and Bridge? Are there any comparisons that people can offer? So, why is there a RoonOS/appliance for manufacturers? This would be an all in one device,no?
The NUC running Roon Bridge should be less noisy electrically. I wouldn’t dedicate a NUC to running Roon Bridge though, I’d use a lower power Arm device like a Rpi, Cubox, Odroid C2. Roon Ready equipment has Roon Bridge functionality embedded in their firmware. I’ve no experience with a Roon appliance, so can’t comment.
ok folks. I went the NUC route and Ubuntu 16.04 and installed Roon Core. i5, 8GB RAM and 250GB SSD.
So far, sounds great. Not able to get native DSD to my Bryston BDA3, I have to use DoP. Been reading forums, no clear answer on native DSD through ALSA for Ubuntu. Any suggestions?
Honestly there’s no advantage to native DSD vs DoP. It’s the same DSD data either way.
DoP takes the DSD data and wraps it with a PCM frame. It doesn’t convert the DSD data stream to PCM. Your DAC is getting the same DSD data either way.
Hi Andrew - Appreciate your prompt response - do you ever sleep? Happy holidays BTW. I wanted to get DSD256, which DoP doesn’t support. Any suggestions?
DoP does support it, but the BDA3 does not. For sending DSD256 over DoP, your DAC needs to be able to receive PCM704/768, while the DBA3 tops out at 384.
It is still early days for ‘native’ DSD support with linux. Here is some development:
The BDA3 was added late august. You’ll need to run Fedora 20 though in order to install the prefab RPMs, or patch and compile everything yourself.
Hi Rene,
Thanks. I want to send native DSD to avoid DoP and get DSD256, which I had when I ran Windows 10 with the BDA USB driver. Any suggestions?
- Read the above (patch your kernel accordingly and/or switch to Fedora and install the needed RPMs)
- Run Windows and use the driver provided
- (My favourite) Forget about DSD altogether
1 Like
Yea trying to avoid patching my kernel and screw something up. Not much now that I listen to on dsd256 so may wait.
Thanks and have a good new year holiday.
Same to you, sir!
Ah, c’mon!!!
That was my first post in well over a day!!!
1 Like
Actually it could be up to a 3rd less bandwidth usage for Native DS stream instead of the DoP so if your network is congested, DSD native might work but DoP not.
However, if your network is that congested, you should rather fix that first.