| Summary: | Audio Volume applet cause excessive CPU usage when visible, especially when on the Desktop | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Danglaxis93 |
| Component: | Audio Volume widget | Assignee: | David Rosca <nowrep> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | frank910311, isma.af, joseph, jsimek.cz, kde, khirehu, nate, nicolas.fella, plasma-bugs-null, postix |
| Priority: | NOR | Keywords: | efficiency-and-performance |
| Version First Reported In: | 6.2.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
VolumeMonitor CPU Usage
VolumeMonitor CPU Usage |
||
|
Description
Danglaxis93
2021-08-26 03:01:52 UTC
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. |