here on "hardy" beta, pulseaudio uses 5% while the system is idle. When I kill it, gnome-power-manager goes to 100% cpu usage! maybe this is a hint on who is causing the trouble? ...

After restarting both pulseaudio and gnome-power-manager, I found that both are idle as they should. But when I unplug the power cable from my notebook, gnome-power-manager seems to play some audio. After that, the CPU usage goes up for pulseaudio.

After executing
sudo /usr/bin/cpufreq-selector -g performance
(so top isn't confused by lowered CPU frequency) I see pulseaudio using approximately 1% CPU when playing music which seems a bit much but not that troublesome. To get your CPU back to use less energy, execute
sudo /usr/bin/cpufreq-selector -g ondemand

I'm also in the pulse-rt group, and have disabled all the multicast and discovery options on my running pulseaudio. When in use, pulseaudio (and in this case last-exit, or last.fm) trade places taking up between 2 and 15% each on my 3ghz P4-HT system. I don't have either cpufrequency or powernowd support enabled (not supported).

I've also experienced this level of usage while padevchooser and gnome-volume-manager were disabled (not running). I don't have any open flash applications, and from padevchooser (before closing it) I confirmed that last-exit was the only application with a Play stream.

I'm on 8.10 Intrepid and while idling with only bash and firefox at 1.5GHz pulseaudio uses 0.7% - 1.3%, though no sound whatsoever is played. Is this normal behavior? As soon as I closes Firefox pulseaudio goes into sleep-mode with 0% CPU-usage.

I have the same problem with my AMD Athlon(tm) 64 Processor 3500+ under Intrepid Ibex 32Bits.
When playing music with rhythmbox , there is at least 10% of the processor used, I do not think it is really necessary for a simple MP3.

Same problem here. My Thinkpad's 1.4 Ghz CPU (mostly running just 0.6 Ghz) is used up to 50 % by pulseaudio when doing nothing (no sound, no other programs used). When I kill pulseaudio and start mplayer, the process is back running again (without me doing anything) and seems to be fine then at about 1-2%.

If pulseaudio wastes CPU idle then trying to play audio into an alsa sink thats a bt device makes it consume 100% cpu and strace is full of messages about MSG_NOSIGNAL. It makes my BT headset unusable.

Confirmed here, too. Pulseaudio ate up to 50% of my 2.0 Ghz CPU, making both the video and the audio stutter in mplayer and totem. What's worse, you cannot stop pulseaudio daemon, and killing the process affects playback quality. The only solution is to completely remove pulseaudio from the system. In my opinion, if it's not fixed by the release it's better to disable pulseaudio by default.

While that likely does lower CPU usage, I also believe it lowers the audio quality. A lot of work has gone into choosing the best default by various community members, with the one chosen found to be the best compromise.

Maybe resample-method should be configurable through the sound settings applet?

It's a huge waste to choose anything but the fastest algo when using pc speakers which I think is quite common. When using good headphones or a mid- to highend hifi you'd want to choose a good algo over a fast one obviously.

When playing a given audio track through mplayer it consumes half the cpu compared to rhythmbox. Interestingly also the pulse process consumes half the cpu when using mplayer.

I did some crude measurements with top and a few different values for resample-method. For these values I used "mplayer -ao pulse" from a tty without X running.
src-sinc-best-quality (overkill, I know) uses between 70-100% and sound stutters with gaps of silence.
src-sinc-medium-quality almost as much stutter as above, after a minute of playing it is almost enjoyable. 30% cpu.
src-sinc-fastest uses about 8% cpu.
ffmpeg/trivial/src-linear all use about 2-3%.

src-sinc-fastest fixes problem. Went from 8-11% to 4-8% which is perfect and it sounds better. I hope src-sinc-fastest becomes default. Also resample-method config in the sound settings applet sounds good. You could make it a slider that goes from performance to quality. To make it easy for non-geeks. If someone is having perfermance or quality problems they can just slide it the way that'll solve the problem.

[ Luke Yelavich ]
* Add a special case to prevent Pulseaudio from being started when the
blindness accessibility profile has been enabled from the Ubuntu live CD,
and for an accessibility install. Unfortunately Pulseaudio and speech do
not currently work very well with each other, and its too late in
the cycle to solve this problem any other way.

PulseAudio takes ~20% CPU when playing audio through amarok, and about 5-7% CPU when no audio is playing, which seems excessive. It has almost as much accumulated CPU usage as X.org :) (currently 68 minutes for PulseAudio, 82 minutes for Xorg).

Pulseaudio hasn't give any advantages for me. The only difference I can see is that now there is completely useless process at the background that takes 10% of my CPU time even when I try to disable it everywhere.

Pulseaudio, KDE4, etc.. When will it end? When Ubuntu stops using alpha state software that is full of bugs and complete unusable?

On Sun, Oct 11, 2009 at 10:09 AM, Henrik Heino <email address hidden> wrote:
> Pulseaudio, KDE4, etc.. When will it end? When Ubuntu stops using alpha
> state software that is full of bugs and complete unusable?

You're free not to use PulseAudio if it bothers you, but please don't
pollute bug reports with this sort of drivel.

Minor confirmation ... on a 4 core AMD system pulseaudio was consuming all of one of my cores. I kill'ed it and restarted it and now it's fine (playing songbird web radio music). I don't know what triggered by the CPU thrash state, but once started it does not let up. (karmic last updated yesterday, Jan 8th)

Let's see -- first thread post two years ago? Looks like this will be a problem for the new user that hangs around like death and taxes. Got here because not only does my sound stutter but the stutters crash the display of Audacious2 on 32-bit 9.10 (sound continues haltingly but Audacious2 is frozen). Called up Top and I got a peak saying pulseaudio was using 106% of CPU. I was impressed. Less stuttering with command-line mplayer but I just got one. Older AMD dual-core with 4 gig and a generic nvidia 9600.

On Sat, Mar 27, 2010 at 6:54 AM, smchris wrote:
> Let's see -- first thread post two years ago? Looks like this will be a
> problem for the new user that hangs around like death and taxes. Got
> here because not only does my sound stutter but the stutters crash the
> display of Audacious2 on 32-bit 9.10 (sound continues haltingly but
> Audacious2 is frozen). Called up Top and I got a peak saying pulseaudio
> was using 106% of CPU. I was impressed. Less stuttering with command-
> line mplayer but I just got one. Older AMD dual-core with 4 gig and a
> generic nvidia 9600.

File a new bug against alsa-driver. Make sure you can reproduce this
symptom using a current (daily) live cd of Lucid.

This is still happening for me on Maverick: pulseaudio is consistently the top cpu consuming process. X is not even on the radar.

I find this situation troubling given that the machine is an Intel Core2Duo E6600 at 2.4 GHz. I did set all the cores to performance governor.

Is this bug still getting attention? Should I open a new bug?

Please let me know how I can help get this resolved. If pulseaudio is not capable of consuming less CPU than, say, X, I would also be happy having an option in System Settings telling the system not to use pulseaudio at all.

Would someone please change the bug status from "Fix Released" -- this is not fixed yet, IMO.
I am aware that 3 years have passed since the original bug report, so if this is not going to get fixed please set the status to "Won't fix" so we won't spend more time on it.

This doesn't sound like a pulse issue but a driver issue. Please file
a new bug using "ubuntu-bug alsa-base", thanks.

On Thu, Apr 21, 2011 at 12:36 PM, Shock <email address hidden> wrote:
> This is still happening for me on Maverick: pulseaudio is consistently
> the top cpu consuming process. X is not even on the radar.
>
> I find this situation troubling given that the machine is an Intel
> Core2Duo E6600 at 2.4 GHz. I did set all the cores to performance
> governor.
>
> Is this bug still getting attention? Should I open a new bug?

Same problem here with maverick and hp2133. Using recording application like gnome-sound-recorder or skype pulseaudio process eats all available cpu time (cpu usage 100%) and the sound is stuttering. tsched=0 helps a bit (pulseaudio not taking all available cpu), but pulseaudio eats still 30% of cpu time. Aplay and arecord works fine.