separate Roonserver.exe as headless core - for server stability and speed reasons serving several clients
separate Roon.exe instance as local output and control only - for local playback to DAC connected to NUC and to nicely show on large TV screen what is playing
Roonserver.exe is managing single database, and Roon.exe is just client without own database connected to the Roonserver.exe.
Roonserver is more lightweight and efficient, since it does not have to carry the overhead of full Roon.
The main advantage is that you can close Roon if not in use while Roonserver keeps on running in the background. I can’t tell you if Roonserver + an always open Roon Remote is more efficient than running just Roon – maybe @danny has some insights on this?
@RBM nailed it. Running them both had the advantage you can close the ui. However, if you minimize the app, an internal shutdown of the gui occurs until the app is restored.
That’s a bit strange… the all-in-one uses shared memory communication, where as the split one uses localhost TCP based remoting. The all-in-one should be way snappier.
Now I’m confused. What’s the point of RoonServer then? And why was I recommended to use it instead of Roon on the NUC as I had performance problems? And why did it solve them?
I can just speak on my experience.
Most importantly - Roonserver is stable and doesn’t crash or become unresponsive as Roon regularly does.
In terms of speed I don’t see very much difference, Roonserver being still somewhat faster.
RoonServer is for when you don’t want a UI attached to your Roon Core. Why? Because you don’t use it that way, you don’t have a head on that machine, you lack the memory on that machine or run on an architecture like Windows 32bit that has limited memory access, or you just want segregation of functionality.
Some setups, like the one @Janis has, has issues with UI+Core in one. That points to the fact that the UI or the memory consumption of the two combined is impacting the setup badly.
As to your performance problems being solved, there are two answers to this:
the split was a red herring and we fixed stuff at the same time to make things faster
the added memory load in one process is impacting your system negatively