Make sure that Roon is as less resource demanding possible

I’ve read a lot of great feature requests in this category. So no need to reply that again.

For now I have actually only one:

Make sure that Roon is as less resource demanding possible.

Looking at the hardware requirements of this great app sometimes seems to me like shooting on birds with cannons.

I’m definitely not an expert in programming at all but it would be great to have the possibility to use it also on less powerful devices more smoothly.

The last build was a good step in that direction.

Maybe someday there will be a Roon light version? I don’t use dsp or other “obscure” options. So for me that would be just fine.

Yep! exactly.
I never use DSP on software. In my opinion you should do this via the output - if you should do this at all :slight_smile:
It would also give the developers the room to strip all small bugs to a possible minimum.

What you guys are “suggesting” somewhat shows the beauty of technological magic.

Here’s what Roon have to say about the architecture, in the knowledge base:

That all this stuff (an average sized library has millions of links if i’m not mistaken) can be done transparently is a testimony to how optimised Roon already is. That someone would think that a coder in their right mind would intentionally bloat their code is somewhat perplexing. But I’m pretty sure that those suggesting that some magic wand be waved to make things “less ressource demanding” have the type of knowledge that would allow them to suggest specific optimisations (which I’m certain are possible).

Your opinion is most likely extremely wrong. Roon’s target reference platform (the NUC7i3) is many times more powerful than your typical endpoint. Demanding the endpoints do the heavy math is, politely put, short-sighted, because it means much more expensive endpoints, not only because you need something more powerful in many different places, but also because, schematically, more powerful = more heat = bigger enclosure or fans. The cost would skyrocket because of this, and you’d end up with setups orders of magnitude more expensive than the current “fast core / light endpoint” paradigm. There’s also a reason to why people ask how many tracks you have in your library before making a CPU sizing recommendation: that’s because the database is the hog, not DSP and other niceties. AFAICT, it’s more of a thing where once you’ve specced a machine you need to handle the nutso database awesomeness, and it’s done doing that, you’ve got enough horsepower iddling around to do cool DSP stuff.

AFAIK, there is one “basic”, ARM-based, Roon Core machine, with a limited version of Roon. It’s sold by ELAC, and the cost to buy it is comparable to building your own NUCi3. Which would you rather have ?

2 Likes

I am not complaining about costs. And an opinion can never be wrong.
I choose not to use DSP at all. That’s also an opinion.

Where did I say you were ?

tl;dr: it’s likely more efficient, ressource-wise, to do things the way Roon does them, i.e, big server with a small client. If you want something smaller, feature-wise, it fits your needs, and money isn’t an issue, get Elac’s device.

Then don’t - no one is forcing you to :slight_smile:

Then ad absurdum, and following your logic, racism and antisemitism aren’t wrong… one learns every day… :man_shrugging:

1 Like

It could help if the (feature) discussion would clarify what’s in focus:

  • Roon Core implementations,
  • Roon Bridge implementations (well, those seem to be quite light weight already - so probably not) and/or
  • Roon Control point implementations (User Interfaces).

The latter got a performance boost on mobile devices lately, if I understood the release notes right. There might be room for improvement for other client systems - on MacOS it feels as if things got a bit better, too - but I’m not sure.

1 Like

@brian commented on it a while back, it mostly had to do with Mono and .NET, so stuff that Roon doesn’t necessarily control, if I understood right. I seem to recall there was some type of optimisation at that level around the time 1.6 was released, but could very well be mistaken there (as well).

Just to be clear–the most recent release included performance work in the core, and some work specific to android.

2 Likes

Thats good news. And thats what I’m hoping for. Thanks Brian

If you classify racism and antisemitism as opinion you may be right. I classify them as sick philossophies.

It also generates a TON of noise and there is a cost to isolating that noise which makes the endpoint cost go way way up otherwise you get to hear some of that noise as part of your music.

2 Likes

I would argue that you do not have to have the knowledge to solve a problem to point out the possibility that there is one. And I’ve been in software development long enough to know that intention has nothing to do with bloated code. That thing blots itself eventually.

My modified (now somewhat ancient) Mac mini 2011 is struggling to work with a small library (~300 albums) and Tidal. It’s an i7 with SSD and 8gb ram but my iPhone still loses connection with core 1/3rd of the times. It wasn’t like this a year ago so Roon is definitely getting heavier to run. So I would say that this is a concern. Even though technology is cheap.

1 Like

I use the core/Nucleus to upscale everything to DSD via DSP before passing it to my Lumin A1 endpoint as DSD, rather than getting the A1 to do the ‘upscaling’.
It works very well, and Lumin would seem seem to advocate this approach.

Have you added (many) Tidal albums to your library during that year ? Pretty sure you’ve thought of it, and definitely don’t want to find justifications for bloat, but could explain at least part of the issues that aren’t a decade-old CPU… not that those slowdowns are reasonable to expect or find acceptable, don’t get me wrong here.