Hello, I am completely new to Roon and have not yet even activated my trial period as I want to get everything set up as well as possible before starting the clock. Please forgive this rather naive question.
I have installed Roon on a Synology 918+ which includes mirrored 256GB internal SSDs. I have read that it is beneficial to have Roon locate its db on the SSD. However, the way my NAS is set up it looks a though the SSD is just a part of the large, single storage volume rather than a separate partition. In this environment, how does one ensure that the database is located on the SSD? Would I need to reconfigure the storage or is Roon somehow magically clever in detecting and utilizing the SSD as it currently is configured?
Kindly note that this device does not meet the minimumrequirement for running Roon Server. You will, most likely, have a much better experience running Roon on a laptop (i3 or better) during your trial.
Edit: I have run Roon on an old HP Proliant Microserver, and it worked fine, albeit the UI wasnāt a fluid and responsive as an i3 NUC. But youāll need an SSD for Roon and a minimum of 8 GB memory. So, my advice still stands: you will, most likely, have a much better experience running Roon on a laptop (i3 or better) during your trial.
Recommendation is not the same as requirement. That said, I run Roon on a very similar (performance wise) Asustor AS5304T Celeron J4105, 8GB memory NAS with good results. And I recognise the issue. You have to be aware that the database is not the location where your files are. I had the same issue and added an external SSD to put the Roon database on. All music on the RAID5-disks. Works great. Just one core in the house and multiple players.
Running Roon on a Synology 1517+. CPU (Atom) is bored, performance is very decent. As long you donāt have crazy large libraries or do weird things with DSP on multiple audio devices at the same time just ignore the minimum recommendations by Roon. At least give it a try. Got nothing to lose.
Thanks, all, for the responses. As I think everyone recognizes, the attraction of using the NAS is that it is already there running and ready to serve. Iād rather not have yet another box (NUC or whatever) doing the same thing.
I think I will try the NAS in any case - my library is not huge: maybe ~600 albums (~8,000 tracks). I guess my original question related to the use of the internal SSD that I have had installed in the NAS from day 1. The OS uses this as cache for frequently used pages - I wondered if this is where the Roon database might find itself when in use and so would satisfy the bandwidth requirement. I suspect the answer is not - or that there is no guarantee - and that I should get an SSD to plug into the USB port (even though USB3 is probably only at best only half the bandwidth of the internal NVRAM on PCIe). (I accept that this question would probably be better asked on a Synology forum but I raised it here on the offchance that someone knew the answer.)
How big is the Roon database likely to be for a library of my size?
Many thanks, again. I look forward to being a part of the Roon community.
Your Synology NAS also has an eSATA port, which is a teeny bit faster than USB 3. The following two products will be more than adequate for an external SSD solution to host your Roon database on:
One great thing about using the DS918+ is that you can access your music offsite via DS Audio on your phone. Your .m3u (non-smart) playlists will sync up with Roon as well if you keep them in a directory where your music is. I love this solution.
Hi,
Iām in the āsameā situation as Hugh. Before investing in a dedicated NUC, I want to try out Roon on my D918+. As it only has 4GB of Ram, I have to upgrade to 8GB or more. If I understood the answers well, thereās no point to install the M2 SSDs, which are used for cache by the Synology?
I ran on 918+ for a year before getting a NUC (which was a great decision for me). The M2 caches will do basically zero for Roon performance (I had them already, and experimented with deactivating them).
If you are going to run on the 918+, during your trial keeping your library on the NAS is fine (as long as you have a backup). For longer term, Iād keep the copy of the library that Roon is accessing on a simple USB enclosure SSD. This has the merits of reducing reads just to get music, but also makes portability if you decide to switch to a ROCK etc (which I predict you will do eventually, but that is up to you) a snap.
Hi Johnny,
Thanks for your answer. By library you mean the Roon database, not the music itself I presume? I still have a spare SSD with USB enclosure here Youāre surely right with the NUC, but at the moment I have to slow down my expenses a little bitā¦
Sorry; ideally you have the database on one tiny external or internal SSD (speed, wear and tear) and your library/music files on another external SSD (wear and tear, portability).
But the budget point is right. Get Roon going and fall in love with it (or not). Anything that runs it is great. Muck around with DSP etc or not to your hearts content. Getting onto a NUC was great for me because I didnāt realize how much my 918+ processor got busy occasionally / occasionally turned off due to power issues, nor how much I personally hated dealing with Docker & NAS performance. My ROCK is just, umm, rock solid and zero thought. But I loved Roon for years before I got into the path of stability above all else.
Tbh, you can run the database on a spinning disk in the NAS for a while if you want to just get started. It will suck. Pause, hang, etc. then youāll get a database Ssd. And from there youāll be off to the races.
Right the M2 caches are a waste. I have 8gb on my 918+, plus I use an external eSATA-cabled SSD for the Roon database, although how much difference that makes in regard to speed is arguably nil.
Iām not following why @Johnny_Ooooops and @DDPS are saying that the M2 caches arenāt helpful. Can you two explain?
I ran my core on a Synology RS1221+ for quite a while. I did ultimately move to a ROCK but that wasnāt motivated by performance or reliability issues. The RS1221+ is a more powerful device than the DS918+, though.
My drive configuration is 4 x 12TB drives in an SHR (2 fault tolerance) configuration. Sitting in front of that are 2 x 480GB SSDs configured as a read-write cache with Btrfs metadata pinned. I understand the tradeoffs with read-write caching.
Measurements (using Synologyās internal tools as well as my own tests) suggest significant performance improvements as a result of the SSD cache tier.
Why are you saying that M2 caches are a waste? Is the point youāre making that you donāt need to put an SSD cache in front of an SSD drive? Fully agree with that but donāt agree that caches donāt make a difference in front of spinning media.
I can get behind that. I wasnāt having Roon issues before I added the cache and I didnāt have issues afterwards. It did benchmark faster but that doesnāt mean anything about real-world perf. Thanks for clarifying.
the particular database that Roon uses (leveldb) is memory resident and flushes to disk periodically for persistence. Cacheing is only going to provide a marginal improvement vs memory + ssd flush. I think (and Iām only playing an architect on TV here, Iām definitely not qualified so correct me if you know better) that if you wanted to improve performance in that architecture your dollars would go much much farther by getting faster or more memory, and then only if you have a large library.
Experience - but seriously ymmv. My experiments led me to experience zero change in snappiness (my catch-all term for search/screen paint/play start responsiveness). When I switched to a fully-specāed (but not over-specāed) ROCK on NUC I saw an enormous change. Enabling and disabling M2 cache did zilch. Adding memory to my 918+ did something noticeable. But if you add up Roon license, and audio hardware, then the differential between bettering my Synology vs getting into āpurpose-builtā machinery was a rounding error. However, it canāt hurt is absolutely right.
All right - you guys schooled me. I should have thought more before writing that initial post. Synthetic benchmarks donāt matter here and the best I can say about my cache install is that it improved those synthetics. Roon worked great before, it worked great after. I moved to a beefy, 11th gen NUC and it works great there, too. I donāt notice any performance improvement on the NUC but I was coming from a very fast NAS with a lot of RAM and the benefits of parallelization that come from SHR (or any RAID approach/tier that enables parallelization).
There is anecdote and opinion on this forum that a database should be on SSD. LevelDB, as I understand it, is a pretty simple persisted key-value store. No indexes, no queries. So Roon must build a fairly complicated in-memory representation which means, at a minimum, either reading everything into memory at startup or demand loading when necessary. So even though itās in memory, thereās at least one read moment where i/o speed is a performance factor. Writes might also be expensive and I assume that all changes are synchronously committed to a log. So, in theory, writes could benefit from SSD drives or cache.
But all of this is just about the mechanics of the thing (including some guesswork) and doesnāt necessarily mean anything about how it all performs in practice.
Iāve used Synology devices for years and years - I love them, I recommend them. I do all sorts of things with them. I have come around, though, to agreeing with the crowd that, in the end, a Nucleus or ROCK (NUC) are the most turnkey, reliable, and supported approaches. Like @Johnny_Ooooops says, Iād probably skip the investments in improving a Synology to get it to work well with Roon and just by a NUC.
All of that said, get things up and running on your Synology. See how it works. Make sure you love Roon (thereās a good chance you will). Then figure out if you need to change anything and, if so, what.
Also, both the OP and I were running on a 918+ which is under specāed. Not awfully so - it works fine without much DSP etc - but enough so that Id bet this explains some of the difference between our experience (or the difference between our NAS/NUC experience differential, difference of difference natch).
Sidebar: wish I could do snappiness benchmarks. But Iām not going to bother.