Hi Frank,
I initially thought about the same thing, but read about issues with direct USB connectivity to the DAC when running RoCK on this hardware. Having the DAC directly connected is however a use case for me, so I opted for DietPi and tried this out with positive results on my existing hardware.
Also this allows for more flexibility regarding partitioning the SSDs so I can gor for a single large drive holding both the OS and the music data.
Regards, Roland
Hi Roland,
I donât use the USB of the GMKtec NucBox G3 Plus as an output for audio.
But if you wish, I can give it a try to see if it works or not.
But if you have decided to go the DietPi-route, then I do not have to test it.
Just keep me informed.
Kind regards, Frank.
Hi Frank,
Iâm referring to this community thread indicating, that USB out to the DAC doesnât work with similar GMKtec devices, so I assume it wonât work with the G3 plus either.
Itâs very likely the GMKtec Intel Nxx-based devices share similar or even identical hardware architecture (chipsets) under the hood just in different form factors.
So no real need to test this with a MOCK setup for me, but maybe of interest for other users.
I will post on my experiences once the device has arrived (at the moment: somewhere between China and Europe 
) and I had time to play with it.
Best Regards, Roland
Hi Roland,
Just out of curiosity, I have tried to connect a DAC via the USB-ports of the GMKtec G3 Plus, and indeed the DAC is not recognized in Roon.
But as a remark: it is never a good idea to connect a DAC directly to the ROCK Server. It is always better practice to connect it via a network Roon Bridge. That does not have to be expansive: a Raspberry Pi on which you install RoPieee is always a good start and is working perfectly. RoPieee is a free software, but is always appreciated if you give a donation to @spockfish when you are pleased with his hard work.
I hope I was able to help you with this answer.
Kind regards, Frank.
Hi Frank,
Iâm a happy RoPiee user (and donator ) for a long time.
However I like to keep my setup simple. I use Roon only for my main listening setup, so thereâs no need to place the RoonServer elsewhere and route the music data over the network. Plus this gives the possibility to turn off the RoonServer if not needed just like any other source component (and donât have to walk into the basement for this).
I have put my NUC7i3 in a silent fanless AKASA Newton case a long time ago for a completely silent ROCK setup. Soundwise, thereâs no drawback in connecting the DAC directly in my setup. I couldnât detect any difference in sound quality to a Pi based streamer or a DDC converting to I2S inbetween. It all sounds the same, which is pretty easy to test by grouping Zones together in Roon, making parallel connections to the DAC and toggle through different inputs while music is playing.
I recently moved back to RoPieee on a Pi4 because my DAC (Ferrum WANDLA) got a significant feature upgrade with the latest firmware update enabling USB HID control via the DACs IR remote for devices connected via USB. This allows playback control through RoPiees remote control feature, so I can play/pause and track skip fwd/back now with the DACs IR remote and donât need to unlock the iPad to do this via the Roon Remote App anymore. Pretty cool.
Regards, Roland
1 Like
@Roland_von_Unruh @Frank_M - Thanks Gents, but I think we need to get back to the topic âDietPiâ.
Thanks and have a nice WE
Torben
2 Likes
It might be more appropriate to say Roon doesnât do any security or updates, just updates the Room App
This is one of the reasons many of us moved to DietPi in the beginning. Open SMB with no password or security, very rarely any kernel or component updates at all
Youâre right, Roon will only update the kernel/OS if there is a vulnerability. Otherwise they leave it like it is. As long as it is safe, they are not taking the risk of changing unnecessary things.
don(t forget that Rock is a very reduced OS. Just the bare minimum needed to do the job.
Kind regards, Frank.
And worth noting that 1) remote vulnerabilities of actual consequence are very rare in the Linux kernel, and 2) local vulnerabilities are typically some way of privilege escalation from a user environment. However, there is no way to connect to it other than through Roon, so you canât simply run exploits from a user shell.
I guess the samba daemon is the one thing that can theoretically be exploited, but their published vulnerabilities should be easy enough to monitor. Anyway, even if you exploited samba and gained access to Roon OS, what then? I suppose there is no real user environment to run much. (I think the Nucleus whitepaper goes into a little detail, IIRC).
1 Like
This has been exploited multiple times, but this is mostly due to user configuration error and poor security choice by Roon to leave it unprotected by a password, and not taking advantage of SAMBA vulnerabilities
Itâs not ideal and even in a family it would be good to protect against accidental changes, but I donât classify known open access on the LAN a vulnerability.
The discussion seemed to be about actual vulnerabilities, i.e., exploitable code flaws.
How has samba been âexploitedâ in Roon?
(In samba at large, there are of course occasional exploitable flaws, like in any similar software. However, a misconfiguration by a user is not really an exploit, either. You can misconfigure anything).
I tried to be careful to say that it was user configuration error linked to poor choice by Roon. If a user sets up their Roon server as a DMZ (yes and sadly it has happened multiple times) and there was password protection enabled there would at least be some friction to stopping someone encrypting all their music. Without a password then it is a perfect 10 on the attack level and nothing for an attacker to do but have fun 
Thankfully there has not been very many recent exploits on Samba and it has become more hardened in recent times
OK, I see. Though in a DMZ nothing will survive long that isnât hardened and properly managed. A password for samba wonât help them much there.
Well it would require some effort at least and if you had a non dictionary password then it could take days or longer to crack.
I used Rock and was a fan for about five years. I think the lack of attention it has gotten from Roon is quite telling. Just added an option to add a password would be something, but now Danny isnât involved in the day to day of Roon I pretty much never expect that to happen.
But I realise that this is a DietPi thread now so I will go back to listening to music
Unless there are remote exploits that are targeted by scripted attacks, and there probably are or will be soon, because the system is running in an environment it isnât designed for.
There are good reasons for this, but the âexploitâ angle simply isnât a relevant one.
As far as Iâve seen somewhere, they seem to be working on that, necessitated by the Windows lockdown on anonymous sharing, and thatâs certainly one good reason.
I donât believe itâs as easy as enabling a password, because this changes the whole security architecture of Roon OS by adding a user account.
No idea what Danny has to do with it, the complaints about Roon OS have been the same for many years while he was around.
I also donât think they are neglecting ROCK, as it is the same as Nucleus. They just seem to think that it does what they want it to do. Largely, I agree (though of course there should be improvements for the password issue at least, and some basic monitoring wouldnât hurt for sure).
These are options available for those who donât want to use Roon OS, such as DietPi, Linux or some other sort, Windows, and Mac. This is how it should be, but I donât see a reason to change Roon OS fundamentally to turn it into one of these existing options. ( And frankly would hate having pushed much additional complexity on me. Iâm perfectly capable of running Roon Server on Linux, but I chose ROCK for a reason and it works great for me).
I thought it was always considered Dannyâs baby and he did all the work I it, at least from my memory, which could be faulty
And yes choice is good and thereâs plenty of choice at this time
Sure, you are right about this, and I meant what Danny has to do with the perceived neglect now that things changed, because the complaints about Roon OS now are the same as they were when he was still leading it.
Yes that is 100% true 
1 Like
Circling back to the original topic on DietPi:
Anyone noticed a performance difference between DietPi and ROCK?
As stated above, in my case DietPi delivers a much snappier user experience than ROCK on the same hardware.
I wonder whether this is due to the fact of mounting the NUC board in a fanless case and making the appropriate settings for fan control in BIOS (i.e. âfanlessâ).
But those are the same for both DietPi and ROCK, and it doesnât seem to affect CPU clockspeeds. At least the cpu command in DietPi shows full 2400 MHz on several cores if needed.
Maybe ROCK runs low performance cpu govenor settings while DietPi runs higher settings by default and can be tweaked further if needed.
I did notice it , but it was 18 months ago, so memory is hazy.
I only saw it when engaging performance mode via the DietPi configuration. It made searching and adding music quicker and maybe because of that opening an artist and seeing their information and albums felt a bit quicker too.