Bug 474487

Summary: Pulseaudio high CPU usahe (16%+)
Product: [Fedora] Fedora Reporter: Mark <markg85>
Component: pulseaudioAssignee: Lennart Poettering <lpoetter>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: basilgohar, covex, jkoelndorfer, lkundrak, lpoetter, msolberg, ruyang, selinux, skr, tomc
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-03 16:21:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
strace from running (but supposedly idle) pulseaudio none

Description Mark 2008-12-04 00:55:19 UTC
Description of problem:
Pulseaudio uses way to much CPU power! here (with only mplayer) it uses 16.2%

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

How reproducible:

Steps to Reproduce:
1. play any file with totem
2. open a console
3. type top and you will probably see pulseaudio on top (or around) with 15 - 20 %!!
Actual results:
i had 16.2%

Expected results:
well.. a few percent at most! specially NOT more then xorg!

Additional info:
CPU is: Intel dualcore T5200 1.6 GHz (acer aspire 5620 notebook)
I was getting the exact same results with both totem and mplayer. And the CPU usage seems to get higher over time. And 16%+ (or even more the 5%) for pulseaudio is totally unacceptable! i rather have the old sound system back then this high cpu resource hog.

Comment 1 Lennart Poettering 2008-12-08 19:24:28 UTC
This might have different reasons.

One might be the simple fact that PA uses a sensible resampler which however causes the CPU load to increase. Consider switching to the "trivial" resampler, which is as bad as the fake ALSA resampler, but should use less CPU.

Comment 2 Tom London 2009-01-23 22:30:45 UTC
Created attachment 329886 [details]
strace from running (but supposedly idle) pulseaudio

I've noticed that pulseaudio sometime approaches 15-20% CPU usage.

When this occurs, I can make it go down by killing and restarting the daemon.

In addition, if I pause all the audio streams  (e.g., by pausing rhythmbox), I would expect pulseaudio's CPU usage to drop to near zero, but it frequently hovers near 5-10%.

Attached is the output of "strace -ttt -p XXXX" of the pulseaudio daemon when it is (supposedly) idle, but consuming about 6-8% of the CPU.

I'm running pulseaudio-0.9.14-2.fc11.x86_64.

Comment 3 Tom London 2009-01-29 21:15:17 UTC
I believe I may have "localized" this problem, at least for me:

On my rawhide x86_64 system, I listen to mp3's all day long with rhythmbox.

Typically, rhythmbox consumes about 5% and pulseaudio about 1.3-3% (as displayed by "top").

I've noticed on occasion pulseaudio jumping up to as high as 20%, and consuming up to about 8-12% even when I pause rhythmbox.

I believe I've narrowed this down to sound originating from firefox: for example, gmail chat sounds and/or flash clips.

For example, playing the flash clips on http://nytimes.com is almost guaranteed to cause pulseaudio to spike to 8-10% and remain there even after flash has "stopped".

The only way I've found to get the pulseaudio daemon to "drop down" in cycles is to kill firefox (or kill/start the pulseaudio daemon).

Documentation from gmail chat indicates is uses flash to generate sounds, too.

I'm using the native x86_64 flash plugin (libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz):
[tbl@tlondon ~]$ rpm -q pulseaudio alsa-plugins-pulseaudio firefox 
[tbl@tlondon ~]$ 

As a "workaround", I've (temporarily?) disabled sounds in gmail chat, and gotten in the habit of quitting firefox after playing flash clips.

Could there be an issue with the alsa/pulseaudio plugin? flash?  Could this be an issue with both .i386 and .x86_64 alsa-plugins-pulseaudio being installed?

Any thoughts here greatly welcomed!

Comment 4 Mark 2009-02-05 22:27:16 UTC
@Comment #3
I had this issues with just playing sounds. I had it while listening to a radio stream either with totem or with mplayer (console based mplayer).

The issues you discovered might just be other bugs with the same effect as the one that i reported.

Comment 5 Adam Pribyl 2009-02-25 11:04:43 UTC
OK, I did a brief trial with audacious and various "backend" plugins:

OSS   5.3% audacious
Alsa  6.6% audacious +  5% pulseaudio
PA   16%   audacious + 15% pulseaudio

I do not know what is the difference of using Alsa and PA plugin but it makes terrible difference.

00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)

Comment 6 John Koelndorfer 2009-03-06 03:04:17 UTC
I can confirm issues with high CPU usage. Here's my audio device compliments of lspci:

00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)

Adam -- looks like we have the same one. Not sure what that could mean.

I usually listen to music via mpd (configured to use pulse output). The pulseaudio and mpd processes usually float between 3-6% each at any given time, although pulse can spike to > 20% at times. For reference, I'm on a dual core AMD X2 6000+.

Skype I think takes it up to around 10%. It gets up to 60+% utilization if I use pulse for input, too.

I would be more than happy to help test/work with someone to resolve these issues, just shoot me an e-mail.

Comment 7 Basil Mohamed Gohar 2009-03-14 06:49:53 UTC
I have a 2GHz Intel Pentium M CPU in my 4-year-old laptop but I've never had CPU problems with audio before.  I can confirm that I am also having the PA-CPU problems as well.  I do not have any nVidia-related hardware, though.

Audio device: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)

Audacious process itself uses more CPU time when running with Pulseaudio (on top of the CPU usage of Pulseaudio itself) than when using either ALSA or OSS.  OSS is extremely trim compared to either Pulseaudio-using backend.

Is the only solution, then, to change the resampling method?

Comment 8 Sebastian Krämer 2009-03-26 13:18:24 UTC
This is very annoying. I'm new to pulseaudio but so far I don't really feel the advantage over pure alsa in my previous setup. Ok, changing resampling method is one thing to fight the cpu load but PA doing *something* while being paused is just unacceptable IMO!

I'm just not used to audio consuming so much cpu power, and especially on a mobile device (laptop) where you want to save as many cpu cycles as you can PA is not helping.

I wish there was an easy way to ditch PA completely and get back to a pure alsa setup (I'm not yet too familiar with fedora so this'll have to wait and isn't top priority..).
All those fancy things that are theoretically possible with PA are too pricy. Just because modern computers do have more cpu power than years ago doesn't mean you should waster them.

Comment 9 Tom London 2009-03-26 13:52:56 UTC
I'm running rawhide.

I no longer see the spikes or the steadily increasing cpu load for pulseaudio.

My use case: I start rhythmbox right after logging in and let it run "all day", typically pausing and restarting numerous times.

This used to cause the above behavior.

I rarely see CPU % for pulseaudio exceed 5%....

Comment 10 Sebastian Krämer 2009-03-26 14:04:13 UTC
Hello Tom,

thanks for the heads up. I'm so new to fedora that I just won't touch rawhide yet. Looking forward to f11 release and see if that fixes the issues for me too.

Comment 11 Mark 2009-03-26 17:24:24 UTC
Now i'm wondering (assuming it's fixed) who fixed it? Fedora or PulseAudio? Because if pulseaudio fixed it then it's fixed for all distributions using it but if fedora did it...

Comment 12 Sebastian Krämer 2009-03-26 18:51:25 UTC
Again, I'm new. But I'd expect the fedora team to push these kinda things upstream. That's logical and that's how it's supposed to work. I read statements regarding this in some 'about fedora' articles, or at least the official one.
However, since there is no further dev comment *here* my guess is that it was fixed upstream because many people complained in general: lookup the topic and you'll find that ubuntu users (to name them) suffered from the same.
Maybe fedora devs or ubuntu (or suse..?) devs helped but I don't worry in either case that patches went upstream.

Comment 13 Lennart Poettering 2009-04-03 16:21:31 UTC
Sebastian: please understand that RH is upstream for PA and ALSA, and many other Linux projects. All our work happens upstream at first.

Closing since apparently fixed in Rawhide.

Comment 14 Michael Solberg 2009-07-16 21:48:59 UTC
For what it's worth, I've still got the same problem in F11 with pulseaudio-0.9.15-14.fc11.

What's the proper protocol to reopen the bug against F11?

Comment 15 Dave Young 2013-12-04 02:03:06 UTC
I have same problem with firefox + flash plugin in F19. I'm disabling pulseaudio and use alsa instead.
I will test rawhide if I find time. Anyone has this problems in rencent Fedora? If so we should reopen it.