I’m thinking of putting Roon onto a headless Mac Mini and was wondering if anyone here had done the same.
I’d like to be able to upsample to DSD 256 and higher if possible. If anyone has a set up like this can they recommend a model/year Mac Mini which would work? I hear the late 2012 i7 model may be the best?
Machines of that vintage are only considered better because you could still upgrade features like memory. Later machines will be more heat efficient but cannot be upgraded beyond their spec at purchase.
You might want to consider a NUC if that’s all you will use it for
The late 2012 quad-core i7 is still a very fast model that can compete with current offerrings. I have the (then) top of the range 2.6ghz model and run it headless. Current models are all i5 except custom config i7 and that’s not even quad-core. It’s a great machine. But sorry i don’t have DSD material or DSD DAC so can’t test upsampling for you…
For any multi-core processes it completely beats the current model, for single core processes not. But for example Roon library scanning will use all cores available if you tell it to, so…
Pretty lame of Apple that a 5 year old machine beats their current model. The line is begging for a refresh…
PS - If you run it truly headless i.e. without any monitor connected, but use remote desktop tools like Apple Remote Desktop or VNC etc to control it, you should get one of these:
It tricks the machine into thinking a monitor is connected, which in turn forces the graphics card to be enabled, whereas without anything connected it is not. As a result the speed and experience of remote desktop use is made a whole lot better.
I didn’t realise the latest hardware only runs fourth generation chipsets. I think a seventh generation NUC will be the equal of the old quad core Mini. But of course, it isn’t a MAC.
I use a headless Mac Mini for Roon core. I also use the HDMI plug that tricks the Mini into thinking it’s connected to a display.
The Mini has nothing else on it and is used only for Roon. It’s been 100% error free.
Same for me - 100% error free. My 2012 Mac Mini has a 500Mb internal drive so I added a USB adapter and a 128Gb SSD drive. The SSD drive now acts as a boot drive and holds Roon database. I found that this change made a big improvement to the speed of Roon. I have a large music library stored on a 4Tb USB drive attached to the Mac Mini.
Just curious, why would you “remote” in to the MacMini? I realise there will be an occasional update and similar, but those are hardly a reason to keep the graphics powered up and consuming cpu-cycles and power?
I think one of the reasons the MacMini works so well as both a Bridge and Core is the absence of graphics an preferably disabled Bluetooth and WLAN.
(Oh, and of course it should have an internal SSD to keep power consumption low and performance high.)
That said, i wouldnt buy a new MacMini for running as Server, i’d go for a NUC+ROCK. The appliance mode is highly appreciated and really lets you enjoy the music, rather than mess with computers.
I have a huge library. In my living room, I’m running Roon Bridge on a Mac mini 2010 Dual Core, dedicated to Roon and Netflix (one at a time). Roon Server is in my study room, on a Mac mini 2012 i7 Quad Core 2.3 GHZ 16GB RAM. I use my iPad as a remote (and as an endpoint, via iPeng). It all works perfectly. I currently do not upsample, but can do up to DSD 256 without any issues.
[quote=“Mikael_Ollars, post:9, topic:34564”]
Just curious, why would you “remote” in to the MacMini? I realise there will be an occasional update and similar, but those are hardly a reason to keep the graphics powered up and consuming cpu-cycles and power.[/quote]
I run other apps on the machine that don’t have remote app like Roon does. For example while I play with roon, I manage my library and add music with iTunes. Also to run backup software, run updates, convert files with XLD, etc etc.
Re: CPU cycles, my understanding is without a monitor attached it is using the CPU to do graphics, therefore more CPU used. With this device the graphics card is doing what it is designed to do. If you never Remote Desktop in then you don’t need it. But if you do it a lot, this makes a night and day difference in how responsive, quick, and smooth remote controlling is.
My old Mac mini is connected to my tv. I use it “headless” (via my iPad) when I run Roon, obviously we don’t use it headless when we watch Netflix on the tv. Are you suggesting that even when I lock the screen and turn off the tv to run Roon, just because a monitor is attached, it is using CPU, decreasing Mac mini’s responsiveness?
Yeah I was considering that but I’d like to use a Mini to test some other non audio related stuff out as well, so it was a two birds with one stone kind of thing.
Thanks for all your input guys, much appreciated.
@koen - My understanding is…
When you have the monitor connected and siwtched ON, then the graphics card is engaged and all should be normally fast when using remote desktop type apps.
When the monitor is connected but switched off the graphics card isn’t used. Which would make sense because in theory the computer doesn’t need to have graphics functions. However when you remote desktop in, it actually does need to perform these functions, so it uses the CPU to do that.
What this device does is trick the computer to use the graphics card all the time, so when you remote desktop in its the graphics card lifting that wieght, not the CPU.
That said, if your monitor is OFF, but you aren’t remote desktopping in, then no graphics functions are needed and there would be no difference in CPU use. This device is really about speeding up the whole remote interface WHILE using remote desktop/VNC/screen sharing.
There’s some more info here…
Thanks @Occamsrazor, that makes sense. Nothing to worry about then, in my case.
Okay, that makes somewhat sense I wouldn’t personally use a headless computer in that scenario, but thats just me
I used to run Roon core on a 2014 i5 Mini. It was and is a real pig. I hate it.
I fail to see the relevance of your comment?
It would help if you illustrate a bit why exactly