I am not buying this.
The Mac Mini M1using Rosetta 2 is MUCH faster than any NUC and there is no reason to believe that there are any issues with the Ethernet stack. There are people using Mac Mini M1s with HQPlayer Desktop doing PCM and DSD upsampling to DSD256 and sent that out to endpoints over Ethernet with no issues. That is much harder on Ethernet than PCM at 24/192…
There are lots of people using Roon Core with the Mac Mini M1 not having problems with Ethernet. Something else is going on…
Nope. I am seriously considering buying two Mac Mini M1 units. One for my Roon Core and another to run HQPlayer…
You are the only person I have seen report an Ethernet problem with the Mac Mini M1 with any software.
@Speed_Racer The Mac Mini M1 doesn’t have an ethernet problem. It’s terrific. Ethernet bandwidth or reliability are not the issue. And I was sure that the small CPU demands of Roon Core would not tax the Mac Mini M1 in the slightest. And this is true. Roon Core uses little CPU on the Mac Mini M1.
I’ve owned Macs for more than a quarter century (going back to the SE/30 in grad school), and I think they are terrific. Apple has left Intel in the dust and AMD scrambling with the M1, and the M1 is just a baby compared to the Apple Silicon processors forthcoming. I do all of my work on a MacBook Pro and can’t wait to get an Apple Silcon version this year. I was strongly biased in favor of a Mac Mini M1 being a terrific Roon Core server.
My network hardware is the same that the founder of Audiophile Style (formerly Computer Audiophile) Chris Connacker uses. It’s small enterprise network hardware from Ubiquiti with vastly more bandwidth than computer audio requires. There is one 24-port switch on the network, and my Mac Mini M1 is wired via Cat 6a (from Blue Jeans Cable; comes with a test certificate). My Synology NAS and Roon endpoint are also connected to the same switch by the same Cat 6a ethernet cable. The network is not a factor.
It took me days to recognize that the Mac Mini M1 could be the issue. Like you, I assumed the processing power and connection to a 1 Gb switch via tested Cat 6a cable would be bulletproof. When I finally switched the Roon Core over to the Windows desktop as a test, the dropouts on 192/24 files went away. The dropouts, by the way, were on two different Roon endpoints.
Even though the dropouts went away, the sound quality was not as good as I had before Roon (e.g., via a battery powered 2012 Mac Mini with heavily optimized Mac OS running Audirvana).
Switching to the Intel NUC running Roon ROCK today solved the sound quality issue and dropouts are gone as well.
Digital audio is carried by analog signals (ethernet, USB, coax). The streamer and DAC have to decide what is a 1 and what is a 0 based on amplitude variations in those analog signals. Also, completely different than copying files, timing matters in delivery of digital audio. When copying files, error correction can just ask for another packet when errors occur. Audio is real time, so there are no do-overs as with copying data to a hard disk. My point being that software absolutely effects audio quality. Roon develops server software for Linux then adapts the software to function on Windows and Mac systems. Roon specifically states that they work with Intel to assure that Roon ROCK (a very lightweight Linux OS) works well with Intel. Specifically, they need the timing of moving packets to be very very precise.
Three weeks ago, I would not have given much credence to the difference between Roon Server running on a good new computer dedicated to the purpose and Roon ROCK running on an Intel NUC. I learned the hard way. Your mileage may vary, but the most helpful input I can give here is to document what I tried and what the results were. As someone who very much likes Macs, I understand your inclination. It could very well work out to go that route. I ran across plenty of people on various forums advising that setting up Roon ROCK on an Intel NUC was the best route for sound quality and reliability. I’m glad I took the time and expense to try it.
Happy Listening!
Hmmm it seems like you’re happy with ROCK (as you should be).
So I doubt you have the motivation to have @support looking into this part I’ve quoted but something is not functioning right here.
From my understanding, Roon is built on Mono, which is a multi-platform IDE.
Not sure what’s going on in your network, but this is not how Rosetta 2 works: it is not realtime translation layer, but rather a recompilation at (first) app launch. Just for fun I assembled a 192kHz endpoint from parts I had laying around (Pi4 + PiDAC+) – not surprisingly the M1 Mac mini core plays Qobuz 192kHz flawlessly.
Perceived sound quality is best left out of this discussion, I think – but hey: if you’re happy, you’re happy.
Absolutely correct. 
kind of an aside here, but when you say 270k tracks, do you mean that you’ve ripped/purchased ~27,000 CDs? Or is it that many of those are added to your library from streaming services?
I’m just trying to get a sense of how many tracks exist as music files vs database entries. (And then how much storage space we are talking about.)
If you think my system is good enough to hear a difference and I still don’t, do you think my ears must be at fault or is there a possibility that I just don’t think there is a difference?
Here’s another one enjoying my new M1 (16 GB Memory and 1TB)! I use my M1 for my Roon Core and I use another 2012 MAC Mini for my Roon Server and it works flawlessly…speedy and no dropouts!
Can’t wait to see what Apple has up their future sleeves !
@RBM @Ray_Mills Yes and no. At 1:39:51 in the Apple Developer Keynote, Apple highlights the fact that Rosetta 2 does Just In Time (JIT) translation dynamically for some code (including Javascript components, which Roon contains if you examine the app package on a Mac).
The “translation at install time,” as Apple calls it, certainly accounts for a large number of apps running well, with a 30% slowdown in some cases and even some speed gains in others. But superficial issues like the snappiness of the user interface don’t necessarily relate to the quality and integrity of the core processes handling audio streams requiring very precise timing.
I have no idea which parts of Roon are running Just In Time, which parts are translated at install time, and what the quality of the translation is as it relates to audio. I do know that I spent days with a fresh, up-to-date Mac Mini M1 system and a fresh Roon Server install (that had completed all indexing and waveform analysis tasks) trying to get 192/24 files to play reliably on two different Roon endpoints over coax and usb.
The only thing that resolved the issue was moving the Roon Server to a Windows machine and then finally to an Intel NUC running Roon ROCK (which improved sound quality compared to the Windows machine).
I think it’s informative to look at what Roon says about Roon ROCK. First, “optimized” is part of the name. ROCK is not adapted to run under another OS like Windows or Mac; it is “a custom Linux based operating system, tailored for running Roon Server and providing a best-in-class, appliance-type user experience to host the Roon Core…[it is] an extremely lightweight Linux-based operating system.” And “We have worked with Intel to support its Intel NUC line of products.”
Optimized
Custom
Tailored
Best in class
Extremely lightweight
Built in collaboration with Intel
Even on an Intel Mac, Roon is running within an operating system that is running dozens of background processes. People have developed guides and scripts the minimize the system overhead on Macs (and Windows computers) that effect audio playback, but neither a Mac nor Windows computer can be pared down to the single function of providing the highest integrity audio data stream. Add to that the black-box uncertainty of what the Rosetta 2 translation is doing, and the answer to the question posed here is clear: If someone is choosing between a new Mac Mini M1 or a Roon ROCK server, there is no evidence supporting the Mac Mini M1 as the better choice. In fact that is very good evidence that the Roon ROCK server is the better choice.
Happy Listening.
I wouldn’t get carried away here. “Some indication”, but not “very good evidence”. And I think if you were to look at a running ROCK machine, you’d also find dozens of background processes. Modern computer operating systems are just built that way.
Roon doesn’t care is tracks are local or added via streaming service, the database grows based on the number of tracks regardless of source as long as they are added to the library.
Most of mine are ripped or downloaded over many years even from vinyl (from dj days in the 80’s) and a lot added from tidal and qobuz too.
Gotcha, was just curious about the sheer volume of files vs qobuz/tidal library entries. That’s a big collection, to say the least.
I’m successfully running Roon Server on a dedicated MacMini M1 (8GB/256GB SSD) with no issues. On original setup, I had it connected to a NetGear ethernet switch which it didn’t like. Once I removed the switch, it worked flawlessly. I chose the Mini simply because I’m used to Apple products and knew that I could re-use it for a different purpose or re-sell the machine if it didn’t work out.
Just in time or at startup, it doesn’t really matter. What matters is that Rosetta is only called into action once for a particular piece of code. After the first instance of running that code it is recompiled, written to disk and read whenever it is needed. The original code is read only once.
@Ray Mills Do you have a source for that? I would enjoy reading up on the ins and outs of what Apple is doing with Rosetta 2.
What I have found so far is that software developers see Rosetta 2 more as marketing. Apple has been clever and the superficial user experience is reasonably smooth, but it’s sausage making under the surface. For example,
"So everyone saying that “Rosetta 2 is AoT translation” as if that means it’s fundamentally better/faster than other emulation technologies is just falling to marketing.
Whatever you call it, it’s not fundamentally different from any other emulator in a way that puts it in another class of technology. It is not straight converting x86 to ARM. That’s just not a thing and it never will be. The end result is that the CPU is going to be executing a series of translated basic blocks interspersed with code added by the translation to glue everything together, which is the same thing every JIT-based emulator does, and will have the same performance characteristics, and the fact that some of that work can be done ahead of time is not a fundamental difference." https://news.ycombinator.com/item?id=25107521
If there wasn’t a performance hit and the potentical for glitches and aberrations in running apps under Rosetta 2 then why would anyone bother to develope native ARM apps for Apple Silicon? It stretches credulity to dismiss Rosetta 2 as a potential issue for Roon server, and returning the original question in this post, there is no evidence that a Mac Mini M1 is a better choice as a Roon server than Roon ROCK running on an Intel NUC. There is ample evidence that the Mac Mini M1 is not the beat choice.
All I have is what I have read. Where and when I read it, I can’t remember.
I have an M1 Mac and a NUC running ROCK and even after what I wrote and understand how the new Apple silicon works, I have no intentions of changing the setup I have. The NUC is more than adequate.
Those that have posted here about the M1 seem to be running Roon quite successfully.