High CPU usage of remote in Wine since Build 903 - some affected users but apparently not everyone

Well you have repeatedly said that all is fine, it doesn’t bother you, it is just like Firefox, it’s what must be expected, it’s our laptops or our fan settings

I don’t think there is reason to quarrel. I see that you intended to be helpful, but unfortunately there is nothing that can be done on the spot that really helps. Debugging Wine might, but I have no experience with that and I just don’t have the time it would cost me.

Please decide what your issue is, the high load or the fan noise. I’m affected by the same high load as you are and wrote so. I don’t have issues with fan noise, most likely because optimizations for my machine are already integrated into the Linux kernel and drivers by the manufacer of my system (and also wrote so), but provided hints where affected users may look for to optimize their own machines.
If you already did look in those areas, already loaded a driver package from the manufacturer, and so on, this is probably not gonna help you (but how could I have known this without asking?) but other affected users may be able to mitigate their fan noise issue with that information. Though I never claimed that this will resolve the high load issue.

My issue is the high load that started with build 903 and leads to a hot laptop, poor battery life, and fan noise :slight_smile:

2 Likes

As most of the discussion so far was about the CPU but the OpenGL based UI also makes use of the GPU, I was wondering if others possibly might see something unusual there? The more GPU load, the more heat, the louder the fan.

As a first data point, here is what I saw running Roon (white theme) in full screen FHD resolution set on the “Now playing” screen during playback of a track with synced lyrics using intel_gpu_top from the package intel-gpu-tools: Peak around 25%, average (estimated Pi times thumb) 10%

I run Roon on Ubuntu 22.04 on a 2016 MacBook Pro (I no longer use MacOS) and also observe the high CPU. However, it has little impact on system performance, and I never here the fan when using Roon.

For various reasons, I only use the AMD GPU; the Intel one is disabled. Hopefully, I’ll receive my new Linux laptop next month, and can make some comparisons

Incidently, BTFS gives me far more grief, with 100% CPU on 8 cores from time-to-time, but at least I can replace this with ZFS when I get some free time

We all know for sure that Roon remote runs OK on 898 and older. IMHO it can’t be rocket science to have the same basic behaviour in later version. This is just a control app, not video player! Come on Roon, you are my most expensive paid software. I really dont want to leave. But I am considering it.

GPU: maybe, but top obviously shows the unreasonable CPU load.

Never had or have any issues with UI refresh or responsiveness even with the Intel GPU.

I won’t be home before next weekend, so can’t compare to your measurement before then

My Dell has an Intel and an AMD GPU. The Roon UI was always easily fast enough with the Intel. When the problem started, I tried running it on the AMD and it makes no difference for me.

As for the effect on system performance, I don’t experience any, either, but of course that’s because I have enough free cores

Actually, I think it’s both. Roon on my wife’s 2015 Macbook Pro is very responsive and buttery smooth, but on my 2018 System76 Oryx Pro running Pop!_OS 22.04, Roon on Wine is sluggish. My guess is that this is because it is congested because it is hammering the CPU. If the CPU problem is fixed, it will be responsive and buttery smooth on Wine too.

Just FYI, same for me after upgrade to Ubuntu 22.10 (kinetic) dev release

I’m running into this same issue of high CPU usage with Roon and Wine. As a workaround, so I can close the GUI when I don’t need it, I’ve installed the native bridge software and in the GUI client, I’ve renamed the RAATServer.exe so that the GUI doesn’t try to launch its own RAAT server. I have a wrapper script that launches the GUI and it checks for the RAATServer.exe before firing up the GUI in case it’s come back after an update and moves it out of the way again. Not ideal, but better than watching my CPU temp go up.

For reference, this is my setup:
Linux Mint 21 Vanessa (Cinnamon)
Wine 7.16 (staging)
AMD 5950X
RTX 3080 (using the proprietary driver, and only one monitor)

I see both Roon.exe around 70% and wineserver 40% continuously, as seems typical in this case.

GPU usage does not seem to be impacted, it hovers around basically zero with Roon running, with brief jumps to 6 or 8%. Nothing to write home about.

To be clear, are you saying you run the GUI under Wine, but use the native Linux RAAT server?

I’m away from home and will look into this when I return. @Suedkiez, what are your thoughts?

I was just reading and wondering myself, but seems that @Timothy_Bathras is running the Core on the same Linux machine, from the full Roon, and therefore it shuts down when he exits the GUI? And by running Bridge separately he gains the ability to keep the music playing when he shuts down the GUI? Just my wild guesses…

I have no experience with this because I run the Core on Rock, so I can always exit the Roon GUI when I’m not using it, and this has been my workaround since this issue started. (Less than ideal, but with an SSD in the laptop the GUI at least starts very fast. Although sadly with Roon 2.0 beta the startup time got a little worse)

I run Core on a separate machine; I run the native bridge on my client machine so that it runs outside of wine and I can kill the gui and wineserver and still have the bridge up and music playing uninterrupted. This way I just fire up the gui only when I need to make a change.

I was also having some audio issues using the raat server under wine, so for me it killed two birds with one stone.

There’s really nothing new here, just reporting my experience.

I don’t get it. I can always quit the GUI and the music keeps streaming from the separate Core machine (ROCK), that’s the expected behavior, don’t need a bridge

Correct, the GUI app has two pieces, the GUI and it also spawns a bridge. That auto spawned bridge also runs under wine, which was giving me issues. This way, the only part of the software that uses wine is purely the gui. When I’m done with using it, I can kill and any wine processes and my music still continues - if I used the built in one, the wineserver proc still runs and was just unreliable for me.

If I wasn’t having audio issues with the raat service via wine, there would be no need to do what I did.

Ok, it’s this part I never had issues with. I quit the GUI, all related processes end, including wineserver, and no more CPU usage. The Core happily keeps playing as it should

If the endpoint that should be playing music is the same PC that runs the remote, then either playback stops when you close the remote (what usually happens on Windows), the RAATServer process must be kept alive somehow (seems to be an oddity of timothy’s setup, for me local pseudo audio devices that show up when using Wine are not functional so I never activated/used them) or you need (the independent from the remote UI part) Roon Bridge running on the PC (natively on Linux – not in Wine).

I understand that, but as far as I can see @Timothy_Bathras didn’t say that the PC that runs the GUI is also the endpoint.

He did say that his Core is a separate machine, so I assumed - maybe wrongly - that the endpoint is also separate. (I guess I don’t understand why one would run the Core on a separate machine if the GUI and endpoint share one machine)

For me, the given description clearly implies that.

If one never uses the same PC for playback, then all this dealing with RAATServer is just not needed as it is never being used for anything. A user could just ignore it.

The Core is a Nucleus(+), ROCK, NAS, powerful PC or just located elsewhere. The remote can be a low power PC without the strength and/or storage capacity to run the Core, a secondary listening zone (like office PC, …) and so on.