I can’t speak for everyone but this is what AudioLinux has done for me. #YMMV
Improved stability I found myself rebooting my ROCK regularly to address hung remotes or sluggish behavior. I am running AL on the same NUCs I was running ROCK. The difference for me is night/day.
SPEED AL is FAST, and can be tuned for even more performance.
Versatility and tweakability I like to tweak and have other things running on my AL machine e.g. DeepHarmony.
KIOSK display I run this as a KIOSK using Firefox as a roon display. With ROCK their is no display.
SQ This one is controversial and the improvement is minimal. However, I found the sound quality to improve, I think this is related to performance and is a small improvement.
I recently moved from Rock to DietPi on my NUC for most of the same reasons as you and was tired of not understanding what Rock was doing when it was slow.
I can comment on any SQ improvements, but everything else has been great and I am doing multi channel output on HDMI with a kiosk display of Room artwork on my TV.
I never tried AL but it was next on my list if DietPi failed me. Happy to report it has been an excellent experience two weeks in.
I do run DietPi on all of my RPIs and I agree, it works great. I had not considered running it as a roon core, but good to know that you have had good success with it. Thanks for sharing that. I don’t know if there is a way to trial AL, but I would encourage you to try it if you can.
Thanks Henry I was not aware of that myself until about 2 months ago.
I am extremely happy with DietPi as a server OS and doubt I will try anything else in the near future, but I have read other good things from AL user’s in the past.
If I do change again then AL will be at the top of my review list.
Like Michael I switched from Rock to Dietpi and it runs brilliantly and allows me to have more control and insight, as well as run other things. It’s been a great experience so far.
I’ll look at dietpi should my standard Debian installation fall over, but being Debian it’s solid.
Rock just kept using more and more memory, my setup now is much better.
Roon does that in general on any system. The more albums artists you browse the more it stores in memory evry search takes up more RAM, yet it doesnt seem to ever release it.
DietPi is based on Debian. It’s just much smaller set of packages installed and the DietPi configuration scripts added. I doubt it be of great benefit to you if you are already using an up to date Debian installation.
F.Y.I. There is a script available to convert a Debian installation to DietPi without having to reinstall the OS from scratch:
The image generation is based on a shell script dietpi-installer:
The script will convert any ‘bloated’ Debian/Raspbian installation into a lightweight DietPi system.
The script will NOT support converting existing installed software (e.g. Nextcloud, Plex Media Server) over to the DietPi system.
All existing software (APT) and user data will be deleted.
The script has to be executed on the running target system which you want to convert to a lightweight DietPi system, or when booting the original image as a container.
Not sure what you trying to show or prove here Dietpi is Debian and all distros work the same way with Roon its the same server component. Roon uses more memory as its used over a period of time, they more things you do the more it consumes. Larger library consumes more RAM top start with. Playback doesnt consume much resources at all even with upsampling I find.
How do you know, it has no tools to check what its using resource wise. This stuff is as much down to software not the OS its on and its the same software on ROCK as it is on Debian.
Surely it is the DotNet framework that should release the memory back to the OS.
After manually rebooting Rock roughly about once a week since Roon 2.0 was released I set up a Cron job in DietPi to run on a Sunday morning at 5 AM and over the last few weeks I have none of my old mid week Roon issues… Of course there is always tomorrow
Yes, I used to manually reboot ROCK regularly & RAM usage was 4gb+ after a matter of days, now it’s less than 2gb after 29 days on the same NUC, the difference being ROCK vs Roon server on Debian Workstation.
I have heard this from other users as well.
It really should not make a difference given that it is a managed language with the same runtime, but clearly it does on some systems
I asked this before but how do you know as you can’t check ram usage in Rock. There are as many regular Linux users who have had ram release issues with Roon so I don’t believe it’s the distro it’s on but the software itself. The fact it doesn’t manifest for everyone also indicates it’s something specific to their underlying user environment that’s causing it. Likely a combo of things they use in Roon, hardware, where music is stored, size of library, how they use the software. Given that the remote crashes that are prevelant don’t affect a large portion of users but for others it does is another example similar in nature.
I wouldn’t put it past Rock having some major bugs mind, Roon has its fair share so I imagine the os does to. But if it was a major memory issue in the os it would affect everyone that uses RoonOS including Nucleus users.
Like you, I had a ROCK server on my NUC and DietPi endpoints when I tried Audiolinux instead for an appreciable sonic upgrade.
I recommend installing the Diretta network protocol (to replace RAAT) as a next step on your SQ journey. Just use AL Menu to implement this approach on both server and target (primary endpoint running AL) for a free demo. If you like the result as much as I do, the €100 license fee will be well worth it.
