Web UI client cpu usage

Using MOD devices
#1

Hello,

this post kind of related to the Web browser category.

I find cpu usage of the ui in the browser to be very high, around 100% of 1 core in Chrome on my old Xeon 2.1GHz. That would not be a problem if used alone, but it actually bothers me as I have other apps open and eventually get xruns, missed frames and other annoyances.

Is there a way to lower this cpu consumption (in the browser maybe, or by tweaking the ModUI in the dwarf). Could the be an improvement to lower the refresh rate (if that matters) when possible ? Should I open a feature request in the forum ?

I noticed the cpu usage is consistently high even in Library or Plugin pages, it only cools down in the Settings Screen.

1 Like
#2

Hi @Sanji.Bo

You didn’t specify whether you’re using a hardware device or the desktop version. If you’re using a Dwarf or Duo(X), the browser is just a view of the device and any XRUNS reported are due to conditions on the device, not on your computer. If that’s the case, you’ll need to analyze and possibly modify your pedalboard to reduce load or spikes.

If you’re using MOD Desktop, then yes, the browser will be competing for computing resources with the audio processing being run by the app.

Probably, but likely not a priority unless there are frequent reports of problems.

My general rule advice is that when you’re using your computer for audio work, try to quit all unneeded applications and close unused browser tabs. The more things you have running, the more the operating system needs to check and manage all those things and that leads to unpredictable loads on the CPU and other unexpected side effects. I once found that Dropbox trying to sync files while my DAW was recording led to artifacts in the output.

5 Likes
#3

Thank you for the comprehensive answer.

I’m using a MOD Dwarf hardware device, hooked to the computer with usb cdc_ether. I understand the browser is just a view of the device, and that’s the reason I find cpu usage on the computer very high.

Chrome or Firefox use roughly a full 100% of a core on Xeon L5630 2.1 GHz (a bit less for Firefox). As the guitar processing all happens in the Dwarf, this does not degrade the audio coming out of the dwarf, but limits what I can do on the computer, that is recording and processing video. I’ve been optimizing the setup to save a few % of cpu here and there, now the elephant in the room remaining is Dwarf monitoring.

For reference, the daw recording and encoding at the same time is less than 20% of a core, and OBS studio is about 100% of a core.

TL,DR;
I guess the solution will be when I can shut down the Web UI while playing music, and turn it back on when I want to change the sound, but at the moment it is not convenient at all.

#4

That is extremely odd. I use an old Lenovo Thinkpad in my music room for tinkering with the WebUI and have not observed any issues. And by old, I mean at least 2 years older than your Xeon – which was released in 2010. Very strange. Do you happen to run Windows on your computer?

#5

i’ve been noticing lately that, with complicated pedalboards, the browser GUI quickly becomes very slow… it still works, but is annoyingly sluggish to use. there’s lots of lag when moving things around, and i have to hold cable plugs over the jack i’m connecting to for quite a while before getting a steady indication that it’s ready to connect so i can release the mouse.

i don’t remember this being such a problem with earlier MOD firmware releases. but i also can’t say exactly when it might have gotten worse.

i’m on a 2018 mac mini. when i look at my Activity Monitor, i see a Brave Browser (Renderer) thread sitting at 110-120% CPU. when i use Chrome, the renderer thread is often even higher… upwards of 135%. in both browsers, the browser GPU thread is typically <10%.

so it seems like there may be some issues with the graphic display in the browser GUI? is there anything an end user can do to help improve this situation, other than building less complex pedalboards? what i tend to build tends to get troublesome in the GUI, while still running very safely in the Duo X when untethered.

later edit: just tested Safari… it seems to be significantly better. interestingly, there’s no separate Rendering thread showing in Activity Monitor. when i’m actually manipulating something, the thread labeled 192.168.51.1 (i guess maybe that’s equivalent to Rendering?) is only tending to be around 100% and it feels less sluggish. also, the CPU recovers much more quickly (back down to around 60%) than the other two browsers, when i stop moving anything.

side-note: also in Safari, when i operate on only a portion of the pedalboard (zoomed in), the CPU jumps down to around 75% and is much more responsive. Brave and Chrome don’t benefit in any substantial way from zooming in.

…looks like Safari for me… although i don’t like the browser for general usage, it seems much more functional for MOD GUI editing!.. :partying_face:

even later edit:

Safari blew up on me… over the course of this morning, editing my complicated pedalboard, it gradually got slower until finally it, and the whole computer, was unresponsive. hmmm… so it’s good, but only for a limited amount of time.

so now i’m trying Firefox… so far it seems the best… stay tuned…

btw, a good and quickly visible indicator of functionality seems to be whether the swirlies around Portal plugins are rotating smoothly or not! :person_shrugging:

@falkTX does all of this tell you anything useful, that you didn’t already know?

much later edit: one final note, then i’ll leave this post be… i’ve now been using firefox consistently for some days with this big pedalboard, and it has not borked once. so, my evidence seems to strongly recommend that as the browser of choice for the MOD GUI. of course, YMMV, and i’d love to hear observations from others!

1 Like
MOD Dwarf - Plugin Portal slows WebGUI