Carl - I appreciate the input. On your test of 4GB with no other apps running (simulating a dedicated machine), were you running Roon? Or RoonServer? But even then the fact is that - unless the Roon developers have gotten past the 4GB limit - Roon is working fine now in a 4 GB space for modest sized libraries. So for now, 4 GB appears to be enough.
As for future proofing, based on the feedback you’ve received, it sounds like they are indeed preparing to make the 64 bit leap. Excellent. However, to REQUIRE more than 4 GB for modest libraries in the 64 bit world is not just a technical issue, it’s a marketing decision. It will impact their business. So now I think we need to hear from Roon.
It was Roon (not RoonServer) but there’s not a lot of difference in main memory requirements between the two, it’s the graphic memory usage that differentiates them.
[quote=“scolley, post:8, topic:3450”]
However, to REQUIRE more than 4 GB for modest libraries in the 64 bit world is not just a technical issue, it’s a marketing decision. It will impact their business.[/quote]I don’t believe so, the price difference 4GB vs. 8GB of RAM is around the cost of one music album … I would suggest it is immaterial. I don’t understand why you want to run with the absolute minimum of hardware … surely it’s not just cost … is there some other reason?
In another topic Danny said this about a MacMini, but that was back in April.
[quote=“scolley, post:8, topic:3450”]So now I think we need to hear from Roon.
[/quote]Yes I agree @Danny I’ve given as much input as I feel comfortable with can you comment further?
Happy to discus “why” I care after we get an answer. What the minimum requirements are (with some future proofing) for a small library is a totally independent question than why I want to know. So I’d rather not go go off topic on a “why does that matter when the cost is so low” discussion until we bottom out the minimum requirement question.
Thoughts about a NAS build using the Atom c2750 CPU/SoC, with an SSD boot drive?
Ideally, RoonServer would be able to run very well on this sort of setup. If there are limitations (on say the CPU), perhaps there are ways to tweak your software to minimize that?
I have been reading this thread but am not sure about one thing:
if I go with a roonserver headless setup on a NUC, will I be able to control and configure it via the remote app on my tablet? Or do I still need the roon software on a client PC to configure roonserver on my NUC?
I am running RoonServer on a BRIX (similar to a NUC) and run Remotes on a PC and on an iOS tablet. The short answer to your question is “Yes” in that a tablet can completely configure RoonServer.
The longer answer is that having some access to the desktop/filesystem on the NUC (which can be done from a tablet but is more convenient from a PC with RDP) is often useful. It lets you restart RoonServer, backup/copy the database or flush the Tidal cache. These may not be things that you do every day, but it can be convenient to be able to do them easily when needed.
fair point. But then I could solve this with a remote desktop app. As I am using a chromebook I could install chrome remote desktop app and control the NUC.
How is the performance of the brix? I have roundabout 12.000 tracks and am thinking about a suitable NUC/BRIX setup. I am just not sure what I need to run a smooth RoonServer and to control it via my Nexus 9 tablet.
I read about i7 setups and 8gb RAM but I really am not convinced that this is the recommended requirement. It is just insane HW setup for a software. I mean, I am not using photoshop or playing games with the nuc. Its sole purpose will be to run Win10 and RoonServer.
Yes, I think a remote desktop app that allows access to the file system on the NUC would be exactly the same as an RDP PC.
I’m using a BRIX S GB-BXi7H-4500u which has a dual core Haswell (4th generation) processor (1.8/3.0 Ghz) with 8Gb RAM. The OS (Server 2012r2) and RoonServer are on a 128GB mSATA SSD and the music (16,806 tracks) is on a 1 TB SATA SSD.
This is certainly more performance than RoonServer requires, but I am planning on running HQPlayer on it when integrated with Roon to upsample Redbook, including Tidal, and possibly also use the convolution engine for Room EQ. That real time processing is the reason for the higher spec and hopefully might be done without turning on the fan (remains to be seen).
Brian’s news that HQP need not be on the same machine as the Roon Core is very interesting and opens up more flexibility of architecture.
Bill - if that question was for the OP, I got an Intel NUC, Core i5 4250U4, 8 GB RAM1, SSD, Windows 10 with Fidelizer - and - QNAP TS-451 NAS, 4 bay (3x WD Red 3TB NAS HDDs1, 1x Kingston 240GB SSDNow V3001 SATA 3 SSD).
And I’ve got a Jitterbug too. But not for my RoonServer. I do NOT want my RoonServer in my audio rack, so am connecting over wired Ethernet to a Cubox-I running the Squeezelite Squeezebox emulator. That little network connected box has the Jitterbug and the connection to my DAC.
I’m sure the NUC is overkill for my meager digital music collection, but I don’t have to worry about upgrades either. HOWEVER…
My heretofore undisclosed motivation for posting was not to decide what Intel platform to buy. I was really trying to figure out if we would ever see RoonServer on an ARM based Linux platform which - at the time of the OP - were typically limited to 2 GB RAM.
Cool! That’s a neat trick with the squeeze lite emulator- I forgot about that!
You hit the nail on the head, I really don’t want a “noisy” computer in my system, yet I don’t what to make of the RAAT or Roon Ready device.
Right now, I have an Apple Airport Express (AAE) connected over wired Ethernet using AirPlay transport protocol. The AAE has a mini toslink/Analog output port. I run a mini toslink to optical cable into my DAC’s optical port.
The AAE works with CD Audio rips and it generally noise free with the wifi antenna turned off.
Looks like using the setup you have is great! Thanks!
I’m going to continue OT for a moment, to close off on this tangent. Since you are connecting to an endpoint over a wired network connection, then…
You’ve got an AAE, and I’ve also got a Aurelic Aries Mini that’s also an AirPlay device. So I don’t need to tell you that it sounds pretty good, but is limited to 16/44.1. My Cubox-i (and some Rasberry PI’s and other ARM devices) running Squeezelite get past that and can run Hi-Res content, including DSD using DoP (providing your DAC supports it). However, all of those solutions are now bested by this little device, that’s really a Cubox-I running RoonReady software. So you’ll get RAAT and - someday - possibly MQA support. And it comes with a low-noise linear power supply, likely putting it sonically ahead of my Squeezelite Cubox-i solution.
BUT before you run out and buy a Sonicore SonicOrbiter SE, please note that Sonicore has announced a follow-up product to the SonicOrbiter SE. Can’t recall the product name, but they have gone on record saying that they will discontinue the SonicOrbiter SE once the new product is released. Just as the Cubox-I is arguably sonically superior to a RPi due to the former being hardware designed from the ground up as a multimedia device, the new Sonicore hardware will be designed from the ground up as a Roon device (only). Thus arguably sonically superior to the SonicOrbiter SE.
Steve, we are committed to the Sonore Sonicorbiter SE long term as an affordable solution. I can’t control availability of some parts, but we will do our best to keep the unit’s available. The follow up product is called the Sonore microRendu and it’s based on the Sonicorbiter operating system. That project is going to be our flagship offering with both software and hardware tweaks. No ETA on that, but we are working very hard on it. Also, it will USB output only and have all the outputs modes the operating system supports available. However, I want to point out that only one output mode is active at anytime to keep the unit sonically pure.
Jesus - thanks for the amended position on the SonicOrbiter SE’s long term availability. Though that’s different than what had been previously been posted online, it’s welcome news. Thank you.
For myself, I’m DYING to be able to purchase the microRendu. But in truth, my own experiences with a Cubox-I based streamer have been so overwhelmingly positive, that I’m sure anyone buying a SonicOrbiter SE now will be delighted with the SQ.
I see this thread is ancient, but hopefully nobody will bite my head off for replying. I managed to get Roon running on an ancient single core Intel NUC. Initial processing will take a long time (at least a week). But playback is fairly responsive, comparing to local use on fast hardware.
I have the same hardware running as a ROCK powered endpoint and it does run ROCK erfectly well. But I don’t use any of its functionality other than the fact my core sees it as a networked endpoint. I have run Roon on a quad core Atom and that can do what is needed better but it is still poor in terms of speed scanning a library and occasional hiccups when multitasking. But overall my i5 is better all round. From speed scanning through snappy response to the comfort of supported hardware it is preferable.
The point of minimum hardware is that our software updates will work fine on minimum hardware, but we make no guarantees of whether a software update will break on your lower-than-spec hardware. We only test on our minimum gear, so if we exceed the spec of some lower hardware, the notice will not be in the release notes, and note that going back to old software is not always possible due to database format changes.
If you are starting from scratch, go for the recommended specs.
If you have gear lying around and are willing to deal with a software update that silently will no longer function on your lower-than-spec hardware, understand the risk.
Agreed, it makes more sense to overshoot a little when buying new things.
Having an updater not work due to lack of CPU cycles strikes me as odd. I suppose if one of your frameworks stop supporting an architecture or start requiring certain CPU extensions it would be understandable.
Having the core and signal pipeline work on a low-power system is a testament to good programming on your end. I was happy the NUC could be used for something productive.
For example, if our search algorithm was improved to reach deeper into the connections in some way to give way better results, but it resulted in an 8 times longer time to do the search. Let’s say a common search took 25ms on the i3 but 500ms on a much slower CPU.
We may be ok w/ these new searches taking 200ms on the i3, but 4000ms would be unacceptably slow. We would never do something that caused this type of result on our minimum hardware.
