Bug 474743 - Pavucontrol uses excessive amounts of CPU when open.
Pavucontrol uses excessive amounts of CPU when open.
Product: Fedora
Classification: Fedora
Component: pavucontrol (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-04 23:33 EST by Nate
Modified: 2008-12-08 16:55 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-08 14:27:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nate 2008-12-04 23:33:37 EST
Description of problem:

I have 2 audio outputs, and two applications playing.. one for each output. Totem-plugin and Rhythmbox. All this causes Pulseaudio daemon to run with about 3-4% cpu usage.

When I open pavucontrol the CPU usage skyrockets. Causes a couple threads for PA to run at about 19% and 12% cpu with the pavucontrol deamon at about 18% and the X server about 36% usage. 

Something like that. Essentially they max out one CPU core completely and start to use quite a bit of the next. Hard to explain exactly how it happens as it's real-time and fluctuates. 

If left alone it will eventually cause PA to fail with the following output:
$ pulseaudio
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
W: alsa-util.c: Cannot find fallback mixer control "PCM".
W: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 1.
N: module-alsa-sink.c: Increasing wakeup watermark to 40.00 ms
Soft CPU time limit exhausted, terminating.
E: cpulimit.c: Recevied request to terminate due to CPU overload.
W: module-rescue-streams.c: Failed to move source output 88 "PulseAudio Volume Control" to alsa_input.pci_8086_284b_sound_card_0_alsa_capture_0.
Hard CPU time limit exhausted, terminating forcibly.

I have myself added to the Pulse-RT group for elevated privilages for the PA daemon, which may contribute to it.

My guess what is happening is that the little GUI volume sliders going back and forth have their sampling rates set to high or something like that. So they communicate with the pa daemon as fast as possible and end up cause X to use a lot of CPU time. 

Although I don't know that for certain.

My guess to fix it would be to add a small delay so that the volume meters only refresh a few dozen times  a second or something like that. Whatever is slow enough to low usage, but still look smooth. 

A similar problem happens when opening the playback volume meter.

Version-Release number of selected component (if applicable):

$ yum info pavucontrol
Loaded plugins: refresh-packagekit
Installed Packages
Name       : pavucontrol
Arch       : i386
Version    : 0.9.7
Release    : 3.fc10
Size       : 244 k
Repo       : installed
Summary    : Volume control for PulseAudio
URL        : http://0pointer.de/lennart/projects/pavucontrol
License    : GPLv2+
Description: PulseAudio Volume Control (pavucontrol) is a simple GTK based volume control tool ("mixer") for the PulseAudio
           : sound server. In contrast to classic mixer tools this one allows you to control both the volume of hardware
           : devices and of each playback stream separately.

How reproducible:

Steps to Reproduce:
1.Play a few media applications
2.open up the pavucontrol application
Actual results:

Excessive CPU usage that causes my laptop to get hot exhaust and eventual death of the PA daemon.

Expected results:

I get to have a nice and easy way to control multiple volume sliders in a window open on one of my desktops.

Additional info:

Other then this and a couple other issues I am quite surprised with the quality of the experience with this version of PA.
Comment 1 Nate 2008-12-08 12:12:46 EST
This only seems to happen when I am running two audio devices. 

On a single audio device pavucontrol seems very well behaved.
Comment 2 Lennart Poettering 2008-12-08 14:27:56 EST
When pavucontrol is running we try to show a volume meter for each stream and device. This volume meter should closely reflected what is is currently played/recorded, hence we activate low-latency settings for the specific device. Now, low-latency means high-CPU load. It's like the Heisenberg uncertainty principle. You cannot have both no CPU load and low latency.
Comment 3 Nate 2008-12-08 16:55:45 EST
That doesn't make any sense at all. 

Why on earth does it make sense to have a volume control that requires so much low-latency for the purpose of providing visual feedback that causes such a high load on PulseAudio that causes Pulseaudio to kill itself!?

It may not be a coding bug and may be done on purpose, but it seems to end up being a pretty bad design bug.  

Because this is what the end user would see:

1. End user plugs in USB audio card. They have read some of the (correct) propaganda about Pulse-Audio being able to effectively manage multiple devices and combined output, which is a attractive feature.

2. So the USB audio device is automatically detected and it's output is added as a option to PA. 

3. The end user then installs pavucontrol since that is the only interface that allows for that sort of controls.

4. They fire up a few apps and the volume control and create a simultaneous output device and begins to enjoy the experience of easy high-quality sound output in Linux.

5. After a few moments all the sound stops. Some of the audio apps tend to hang. The volume control says it's lost it's connection.

And that's about it. bingo. Dead sound. Why? Because the high-load caused PA to kill itself for eating to much cpu time. But this is entirely non-obvious and is confusing. The only want to figure out that the volume control caused PA to kill itself was to re-run the entire thing, but with PA running from a xterm so you can see the error codes.

This is exactly what happened to me. Is this my fault for trying to run multiple outputs or something? Or maybe because I added myself to Pulse-RT or whatever?

I mean, sure, if you have some sound visualization app or your trying to monitor levels for studio work or something like that then having low-latency visual feedback with high sample rates would be something that you'd want to have.. but the purpose of the volume control stuff is just a way to see the relative volumes and doesn't really need a very high sample rate or very low latency. 

That's what I figure anyways. 

I am not going to fight you on this or anything like that. I could be missing something entirely and is being entirely retarded about it. But what you said just sounds wrong.

Note You need to log in before you can comment on or make changes to this bug.