high cpu usage
Activity
For me, deselecting "Show volume meters" avoids the issue.
But with it being selected, the high CPU usage occurs even in tabs where no volume meters are shown, such as the Configuration tab.
IMHO, the behavior should be improved, because this high CPU usage activates the fan of my laptop, with probably battery drain when on battery.
Hi @vinc17 could you please have a look if cpu usage is due to pavucontrol process or pulseaudio process? E.g. look in the
topsorted by cpu usage.If this is due to pulseaudio process, please attach your
pa-infooutput.If this is indeed due to pavucontrol process, can you do some profiling of what it's doing? E.g.
perf top -p <pid of pavucontrol process>would be a good start.Edited by Igor KovalenkoFor
pulseaudio, about 5-6% CPU time. Forpavucontrol, about 4% in the Playback tab and about 2% in the Configuration tab. This doesn't seem to be very high, but this is sufficient to activate the fan (otherwise the machine is mostly idle, so this is a huge increase of CPU usage).pa-infooutput: pa-info.outHere's what
perfsays forpavucontrol:8.48% [kernel] [k] syscall_exit_to_user_mode 3.56% [kernel] [k] __entry_text_start 3.42% [kernel] [k] syscall_return_via_sysret 1.88% libpulsecommon-15.0.so [.] pa_fdsem_after_poll 1.63% [kernel] [k] psi_group_change 1.62% libglib-2.0.so.0.7200.1 [.] g_main_context_check 1.60% [kernel] [k] __fget_light 1.28% pavucontrol [.] Gtk::TreeRow::set_value<Glib::ust 1.22% libgtk-3.so.0.2404.29 [.] gtk_style_properties_lookup_prope 1.13% [kernel] [k] do_sys_poll [...]and for
pulseaudio:2.72% [kernel] [k] __fget_light 2.68% libpulsecore-15.0.so [.] pa_resampler_ffmpeg_init 2.55% [kernel] [k] syscall_exit_to_user_mode 2.12% [kernel] [k] do_sys_poll 1.91% [kernel] [k] psi_group_change 1.60% [kernel] [k] sock_poll 1.53% libpulsecommon-15.0.so [.] pa_fdsem_after_poll 1.46% libpulsecore-15.0.so [.] pa_play_memchunk 1.23% [kernel] [k] preempt_count_add 1.21% [kernel] [k] _raw_spin_lock_irqsave 1.10% [kernel] [k] __entry_text_start 1.10% [kernel] [k] syscall_return_via_sysret 1.06% libpulse.so.0.24.0 [.] pa_mainloop_dispatch [...]If your audio hardware supports 48000 rate and you are usually playing 48000 audio your system may benefit from
default-sample-rate = 48000in/etc/pulse/daemon.conf, this should help with cpu usage by pulseaudio daemon by removing the need to resample.2..4%does not look that big, guess noone looked into whether that could be improved. You can slightly reduce cpu usage by making a change to peaks resampler rate, reducing it will also reduce painting overhead:diff --git a/src/mainwindow.cc b/src/mainwindow.cc index 2e1c58b..7155fca 100644 --- a/src/mainwindow.cc +++ b/src/mainwindow.cc @@ -666,7 +666,7 @@ pa_stream* MainWindow::createMonitorStreamForSource(uint32_t source_idx, uint32_ ss.channels = 1; ss.format = PA_SAMPLE_FLOAT32; - ss.rate = 25; + ss.rate = 10; memset(&attr, 0, sizeof(attr)); attr.fragsize = sizeof(float);Edited by Igor KovalenkoActually I now don't think that the CPU usage is really the issue. The
powertoputility gives interesting information when running on battery (i.e. with the power cable unplugged).Without
pavucontrolrunning:The battery reports a discharge rate of 16.9 W The energy consumed was 400 J The estimated remaining time is 3 hours, 53 minutes Summary: 765.7 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 9.2% CPU use Usage Events/s Category Description 2.2 ms/s 206.8 kWork dbs_work_handler 1.7 ms/s 76.4 Timer tick_sched_timer 5.7 ms/s 66.5 Process [PID 18654] /usr/local/firefox/fi 4.2 ms/s 59.7 Process [PID 18719] /usr/local/firefox/fi 3.9 ms/s 57.7 Process [PID 19348] /usr/local/firefox/fi 5.3 ms/s 51.3 Process [PID 18659] /usr/local/firefox/fi 12.8 ms/s 46.5 Process [PID 19340] /usr/local/firefox/fi 7.1 ms/s 20.4 Process [PID 18537] /usr/local/firefox/fi [...]With
pavucontrolrunning, Configuration tab:The battery reports a discharge rate of 23.3 W The energy consumed was 468 J The estimated remaining time is 2 hours, 45 minutes Summary: 1325.7 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 13.5% CPU use Usage Events/s Category Description 4.3 ms/s 361.7 kWork dbs_work_handler 30.7 ms/s 127.9 Process [PID 6529] /usr/bin/pulseaudio -- 3.2 ms/s 156.7 Timer tick_sched_timer 100.0% Device Audio codec hwC1D0: Nvidia 5.5 ms/s 66.4 Timer hrtimer_wakeup 9.8 ms/s 50.7 Process [PID 27446] pavucontrol 11.4 ms/s 49.2 Process [PID 19340] /usr/local/firefox/fi 2.8 ms/s 47.4 Process [PID 18719] /usr/local/firefox/fi 595.1 µs/s 48.3 Interrupt [6] tasklet(softirq) 1.5 ms/s 47.0 kWork hci_tx_work 0.9 ms/s 46.1 kWork hci_rx_work 5.2 ms/s 44.0 Process [PID 18654] /usr/local/firefox/fi [...]With
pavucontrolrunning, Playback tab:The battery reports a discharge rate of 23.4 W The energy consumed was 470 J The estimated remaining time is 2 hours, 44 minutes Summary: 1409.7 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 14.9% CPU use Usage Events/s Category Description 4.4 ms/s 382.7 kWork dbs_work_handler 26.0 ms/s 160.7 Process [PID 6529] /usr/bin/pulseaudio -- 3.5 ms/s 166.0 Timer tick_sched_timer 100.0% Device Audio codec hwC1D0: Nvidia 22.0 ms/s 70.1 Process [PID 27446] pavucontrol 5.4 ms/s 69.5 Timer hrtimer_wakeup 0.9 ms/s 49.3 Process [PID 18659] /usr/local/firefox/fi 492.6 µs/s 48.6 Process [PID 19348] /usr/local/firefox/fi 551.8 µs/s 48.3 Interrupt [6] tasklet(softirq) 1.5 ms/s 46.9 kWork hci_tx_work 0.9 ms/s 45.8 kWork hci_rx_work 2.3 ms/s 41.0 Process [PID 18719] /usr/local/firefox/fi [...]See the energy consumption. The issue might be the "Audio codec hwC1D0: Nvidia" usage.
After doing additional tests with
powertop, it seems that there is no issue when I runpavucontrolif "Show volume meters" is initially unticked. But if I tick it and untick it again, the problem with energy consumption and "Audio codec hwC1D0: Nvidia" 100% usage occurs again... until I quit pavucontrol.Ok this could be pulseaudio problem. If I stop all audio players and run pavucontrol with volume meters initially unticked the monitor source from which pavucontrol reads peaks stays
SUSPENDED. If I tick volume meters and then untick again, that monitor source goes toIDLEbut never toSUSPENDEDagain. If I close pavucontrol, it returns toSUSPENDED.At the same time, the sink corresponding to that monitor source also goes into the same state. If it does not return to
SUSPENDEDthere will be no suspend call to alsa which likely prevents device from suspending.You can check state with
pactl list | grep -A1 -E "(Sink)|(Source)"it should go like this andStateis displayed on second line; hereSource Output #29is pavucontrol with peaks resampler:Sink #0 State: IDLE -- Monitor Source: alsa_output.pci-0000_04_00.1.hdmi-stereo-extra3.monitor Latency: 35870 usec, configured 40000 usec -- Source #0 State: IDLE -- Monitor of Sink: alsa_output.pci-0000_04_00.1.hdmi-stereo-extra3 Latency: 0 usec, configured 40000 usec -- Source Output #29 Driver: protocol-native.c -- Source: 0 Sample Specification: float32le 1ch 25Hz -- Source Latency: 0 usec Resample method: peaksHi @vinc17 I now added pulseaudio!697 (merged) fix which should allow pulseaudio to release devices when you untick
Show volume metersin pavucontrol. Would be nice if you could test that change and confirm it works for you.I've just tested with and without the patch, and I confirm that the patch fixes the issue when I untick
Show volume metersin pavucontrol (i.e. everything goes fromIDLEback toSUSPENDEDafter a few seconds).
mentioned in merge request pulseaudio!697 (merged)
I'm having a similar issue, but not linked to suspend/idle.
Whenever pulse audio volume control is running, 1 of my CPU cores is maxed out. The process is:
/usr/bin/pulseaudio --daemonize=no --log-target=journal
I'm running:
Linux XXX 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64 GNU/Linux
on a desktop PC. I have a Juli@ sound card, GTX 2080 Super (with HDMI output) and an Avantree USB bluetooth device. I don't recall this behavior prior to installing the graphics card.
pa-info gives the following output:
Thank you for any thoughts on how to troubleshoot/fix this issue.
ETA: when I run
pavucontrolSummary: 3036.1 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 15.0% CPU use
Power est. Usage Events/s Category Description
1.36 W 4.8 ms/s 340.1 Process [PID 1614] /usr/bin/pulseaudio --daemonize=no --log-target=journal
1.33 W 5.9 ms/s 333.2 Process [PID 1713] /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xautho
1.31 W 23.9 ms/s 322.9 Process [PID 1721] /usr/bin/pulseaudio --daemonize=no --log-target=journal
500 mW 100.0% Device Audio codec hwC3D0: Nvidia
500 mW 100.0% Device Audio codec hwC2D0: Realtek
Edited by dantzler@dantzler The
SUSPENDED/IDLEissue is just part of a more general issue and is about untickingShow volume metersin pavucontrol without restarting pavucontrol. What you haven't said is whetherShow volume metersis ticked or not in pavucontrol when you start it. If it is ticked, this is this issue. If it isn't, this is some unknown issue.@vinc17 - thank you very much!
I unticked
Show volume meters, closed pavucontrol and restarted. The issue went away.
Same issue here. When that volume meters are enabled, the CPU load from pavucontrol goes to 3-10% (before 0.3-3%) and the worst part, the Xorg process usage changes to 11-17% (before about 3%). That means: the consumption of the current solution is almost a whole Ryzen core of CPU load.
IMHO that deserves at least a warning when somebody ticks the VU meter checkbox.
One way to reduce CPU usage at least in some situations might be to allow throttling those vumeters' refresh rate when the window is not in focus; same idea as https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/3263
Also related: #27
Edited by Jeff Fortin Tammentioned in issue #42
