What about GEEKOM A9 HX 370 & AudioLinux vs a ROCK NUC?

My Roon/ROCK Intel NUC11; PAHi7 was recently “toasted” by a nearby lightening strike.:anguished_face: :face_with_symbols_on_mouth:

I’m considering moving from the ROCK approach to an AudioLinux one.

My library is ~250k FLAC tracks stored on an 24TB USB HD. DSP is not used.

Hardware being considered: GEEKOM A9 Max (2026 Edition) with AMD Ryzen AI 9, HX 370 and 32GB RAM.

The PC will not be located in the dedicated 2-channel SoundLab 845PX (full-range esl’s) audio room, so noise isn’t a problem. But the Roon server will run 24/7.

Is this equal to, or better than running ROCK on a NUC?

Never having fiddled with Linux, is loading and running AudioLinux fairly straightforward for a newbie, with a bit of software and hardware expertise? Is this a prudent direction? Any and all advice is appreciated!!

Is this something you WANT to do? If not, then why bother. It will certainly be messier and more time consuming than using ROCK. If you want a cleaner Linux with RoonServer experience and something other than ROCK, I suggest DietPi for PC.

Being into highly resolved audio in the 2-channel room, I was veering towards AudioLinux because of info like this:

“AudioLinux is the audiophile choice: Real-time kernel, low CPU latency (<1µs possible), and tools for prioritizing audio/network tasks can give smoother library browsing, faster analysis, and potentially better subjective sound quality from the server. Running the system in RAM is a nice bonus for reactivity.”

But I’m asking the question because I haven’t any experience with either DietPi for PC or AudioLinux. I have no problem with paying for the latter, if it provides a better sonic and operational experience given my 250k library. But I’m seeking real-world experience with either, rather than info. aggregated from the Internet or AI.

In any case, is the Geekom A9 HX370 with 32GB and DietPi or AudioLinux a good marriage of hardware and software? Is there something appreciably better?

I use AudioLinux a lot on endpoint devices (I’ve built more than 70 of them for myself and friends). So, I’m definitely a fan. But the main use case for this highly tunable operating system, based on Arch Linux, is feeding a directly connected DAC (typically via USB).

There are no sonic advantages to using AudioLinux vs any other compatible Linux distribution if your use case is running Roon Server from another room. In fact, AudioLinux will perform slightly worse because of processing constraints enforced by its real-time kernel.

If you won’t be connecting a DAC directly to your server, there more novice-friendly Linux distributions than AudioLinux. I would use the latest Ubuntu Server (a little more user-friendly) or Debian Trixie instead.

You will receive polarised views on this. Audio Linux uses a real time kernel, which is designed for manufacturing and financial systems where a transactions must be performed in a predetermined period.

In contrast, pro audio uses a low latency kernel because many channels at high bit depth and sample rate are processed simultaneously.

For something as undemanding as streaming music, a general purpose kernel is all you need. @Rugby’s suggestion is ideal if you are new to Linux in this context.

Translation: nothing real

Good advice, exactly what I was seeking…Thanks!!

So far 3-Linux versions have been mentioned as follows:

David_Snyder:

I would use the latest Ubuntu Server (a little more user-friendly) or Debian Trixie instead.

For a Linux neophyte, but an old hand at DOS/Windows and dabbling with a couple Mac’s, I believe I can learn what I need. But is one easier, better in some way(s), over the other(s) as a Roon server – i.e. how do I choose?

Lastly, any comments about the Geekom A9 HX370 as a Linux Roon server? On paper, it looks to be more than capable. Are there any other (out of the room) PC options that would be equal or better for a 250k library, but when NOT using DSP?

Note: My EMM Labs DV2’s input is Ethernet.

DietPi is minimal Linux distribution with a nice little text-based UI that lets you do what you need for the Roon server purpose and more. The admin UI offers a selection of media software packages and you can install Roon Server from the menu.

DietPi is Debian based, if that matters. Try it, it’s free. If you don’t like it then wipe it and try a different distro.

Just so you know, installing DietPi and setting RoonServer running on it, is only a few minutes longer than running ROCK. DietPi has an ansi graphic menu that you scroll down and mark what parts you want to install. Very Easy.

Thanks Rugby, very helpful!

My understanding is that ROCK is Linux based. Is there any inherent reasons sound wise to run ROCK vs Linux.

Some have mentioned that one of the positives of Linux is that it offers temperature measurements and other mainly hardware controls that ROCK doesn’t.

Are there other advantages of Linux over ROCK &/or vice versa?

No. There is no sound at this stage, just digital data.

ROCK comes from Roon directly, so as long as you run it on compatible hardware, it “works.” But it is designed as an appliance, with minimal interaction allowed. Which might work fine for someone who does not want to do anything other than turning it on.

Some other Linux distribution might be slightly more difficult to get Roon running on, but would allow one not only to run something else on the same computer, but also to manage it properly, At the very minimum, connecting a server (any server, really) to a UPS and having it shut itself down gracefully if the power goes out is the very basic requirement for anything that wants to call itself a server (and also, Roon uses a truly terrible “database” that corrupts itself easily, especially if power goers out in a middle of some process). Personally, I would never touch ROCK with a 10-foot pole.

Sound-wise, of course, there will be absolutely no difference no matter what OS you chose.

Before the lightening strike that affected the Roon/ROCK/NUC, I successfully ran ROCK for approx. 3-years. However recently,:anguished_face: Roon’s searches and the database in general had slowed way down. Restarting the NUC/ROCK returned the speed to what it should be. But after a short period of time processing would again decline. I’m not sure if it was hardware or recent Roon upgrades. Nor do I know if it was ROCK related.

Do you think that new hardware and especially a Linux server might remove such headaches?

Of course, that’s assuming a DietPi &/or other Linux distros will be as fast, or faster than ROCK (with 250K tracks) and will be as robust & rock solid (no pun) as ROCK was for 3-years.

There is a known issue with memory leaks in Roon Server that’s currently getting addressed, and which exhibits exactly in the behavior you described, as is being extensively discussed here:

Perhaps you want to upload your database as requested by Roon Labs in the linked post (and subsequent posts)

There’s no reason for a significant performance difference between ROCK and DietPi, both being rather minimal Linux-based variants. Most likely, ROCK might be a tiny bit faster as it’s probably running even less processes, but it’s probably insignificant.

Of course, faster hardware always helps, but the issue is most likely in Roon Server (either the one described above or some other one) and this would be the same with ROCK and another Linux variant, as they all run the same Roon Server, and faster hardware may not be a permanent solution until Roon Labs fixes the issue.

There’s no real reason for DietPi to be less reliable either. It would give you more insight into memory behavior (if you are suffering from the leak) than ROCK, which gives you nothing.

Good to know…Thanks!

Basically, what @Suedkiez said – if your performance has been adequate until now, the problem is far more likely to be the memory leak in the current version of Roon.

On the same hardware and under the same workload any performance differences between different flavors of server Linux are bound to be minuscule.

Personally I would only run a server on something that allows for proper monitoring and management. We get power outages often enough here, and even my Synology box is smart enough to realize when it happens and shut itself down when the UPS battery runs down. And… I actually know how much memory Roon is using on it.

I too would like some knowledge and control over the hardware; hence, why I’m veering away from ROCK. Although a lose nut may be behind the steering wheel, I still like to do the map (Waze) reading and driving!

Also, the hardware limitations of ROCK, although are work-around-able, are a bit of a pain!! That is, the newer NUC’s are NOT YET approved by Roon for ROCK. Although I’m a fan of the forum, for newer NUC’s, why the heck should I have to go to another forum like Audiophile Style (Installing ROCK on an Asus NUC 15-Pro) to read about how to install ROCK &/or to know if ROCK will even work on newer NUC hardware?:angry: Isn’t our yearly leasing of Roon sufficient compensation for newer ROCK hardware testing?

As a side note, with the ROCK NUC, we also had several power outages and with no UPS, the NUC always successfully (manually with a button-push) booted back-up. But maybe luck was going my way, that is, until the nearby lightening strike just took the NUC offline permanently.:anguished_face:

There are threads about this here on the forum as well :slight_smile:

Yes indeed, I found threads on the Roon Labs Forum about yet-to-be approved NUC’s, before I found Chris Connaker’s review of his positive experience loading Roon on a NUC 15 Pro.

However, for almost 20-years from his 1st. website (2007), the “Computer Audiophile” and now, his Audiophile Style website, Chris has developed a superb reputation in the PC audio/audio world. I’ve also had cogent and helpful communications with Chris, and thus, his commentary and advice carries a bit more gravitas about a specific subject, then forum posters in general. But of course, this is the same reason why a :+1: from the Roon professionals re approved NUC hardware is so revelatory, important and sorely needed.

I was just saying that you didn’t have to go there as this seemed your complaint