SUMMARY Audio Volume applet causes high CPU usage spike and the current workaround is to disable the applet via System Tray Config. More details: https://www.reddit.com/r/kde/comments/pbbzqh/plasmashell_suddenly_eats_up_100_of_cpu/ STEPS TO REPRODUCE 1. Install Arch Linux and KDE 2. Open htop and see plasmashell consuming 50% of all CPU cores usage for about 1 second 3. After about 5 seconds the usage drop down to normal and spike up again a few seconds later OBSERVED RESULT Endlessly 50% usage CPU spike from plasmashell service (causes by Audio Volume applet) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 Kernel Version: 5.13.12-xanmod1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Memory: 15.1 GiB of RAM Graphics Processor: AMD RENOIR ADDITIONAL INFORMATION I kill the process and start it in the terminal to monitor the error output. Here is the result (https://pastebin.com/YrNTUeqS). Everytime the line "qrc:/plasma/plasmoids/org.kde.plasma.volume/contents/ui/ListItemBase.qml:233: TypeError: Cannot read property 'visible' of null" appear the CPU usage spike up
How can you tell that it's being caused by audio volume applet? If you disable the applet, does the CPU usage go down or something?
Yes, there will be no more CPU spike every 15 seconds if I disable the volume applet
Created attachment 142772 [details] VolumeMonitor CPU Usage I'm also having this issue. I believe it has to do with the somewhat new VolumeMonitor feature. OBSERVATIONS: When the applet/widget is opened manually (from the System Tray widget) or when it's always open/active (like when placed in the Desktop), the VolumeMonitor will create a PA record stream for each available sink. I'm guessing this is what causes a high CPU usage, because when I terminate or mute the recording (from a control tool like pavucontrol) the CPU usage drops to normal values. It might also be that it's not the recording but the the UI update of the widget, I'm not quite sure how to differentiate, though even when the widget is covered by other windows it still consumes CPU. I'm adding a video attachment demonstrating this behavior. SUGGESTION: It'd be nice to have an option to disable this monitoring of the volume levels in the settings of the applet/widget. OPINION: Tbh, it's quite troublesome to not be able to have this widget on the desktop due to this having it consume my quite limited amount of CPU power. Of course, I can temporarily solve it by terminating the recording streams or making a scheduled script that kills this recordings after they spawn. But I don't see this as very viable or pleasant.
Created attachment 142775 [details] VolumeMonitor CPU Usage RE-UPLOAD of previous video attachment, cropping unnecessary portion of the capture. PLEASE Staff, delete the previous one. It may or may not contain unintended sensitive data :)
I forwarded your request to sysadmins.
The content of attachment 142772 [details] has been deleted for the following reason: requested by uploader (T14965)
*** Bug 448032 has been marked as a duplicate of this bug. ***
Does this also happen when having pavucontrol open?
Yes. I can accept that this is just a very CPU-intensive thing (though I think it should still be improved) but it definitely shouldn't keep recording stuff while the UI that shows it isn't even visible. This works for the tray representation when the popup isn't visible, but doesn't work for the applet on the desktop when it's completely covered up by other things. Maybe that's a thing that be generically fixed elsewhere though? Like suspending any widgets whose content is 0% visible?
Our volume monitor code is very similar to the volume monitor code in pavucontrol (I wonder why :P). If they don't seem to be able to make it more efficient I'm not sure we can.
> Maybe that's a thing that be generically fixed elsewhere though? Like suspending any widgets whose content is 0% visible? That's probably kind of doable, but likely would need support from the compositor on Wayland. That said we need to be careful with that, forcefully "pausing" applets could have unintended sideeffects
I can see the potential risks of that; perhaps there's an applet the produces sound and you might want it to continue doing so even when it's on the desktop yet covered with windows. Could we just stop rendering it, though, rather than suspending it completely? Or perhaps instead or in addition, we could add a "pauseable" property that apps can set if they know they are going to be doing CPU-heavy stuff, which would cause them to be suspended when not visible.
Are there any updates on this bug? I just discovered that I'm having this exact issue. Although the CPU usage is only at ~8% on my i5-1135G7, the idle power usage measured by powertop and powerstat increases from ~3w to ~8w, massively impacting battery life. Monitoring with pw-top shows that plasma-pa is using all the alsa_input's and occupies significant CPU time. Interestingly, the speaker don't seemed to be used by plasma-pa.