[alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
Hi Lennart,
We found that pulseaudio eats CPU ~19% CPU time, a little more than mplayer when playing video. This is horrible for laptop batteries.
Can we make it just work -- in green CPU mode? I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
Thanks, Fengguang
'Twas brillig, and Wu Fengguang at 14/04/10 08:56 did gyre and gimble:
Hi Lennart,
We found that pulseaudio eats CPU ~19% CPU time, a little more than mplayer when playing video. This is horrible for laptop batteries.
Can we make it just work -- in green CPU mode? I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
Things to check: 1. Is it your driver providing bad timing information to PA: Check by enabling tsched=0 for module-udev-detect in default.pa 2. What is the native sample rate of your h/w. PA uses 44.1kHz by default but perhaps your h/w is using 48kHz only? If so set default-sample-rate = 48000 in daemon.conf 3. Do your videos require resampling. If you prefer battery life over sound quality, try using a less CPU intensive, but lower quality, resampler. See the settings in daemon.conf.
Or do you just mean that when on battery, the resampler should be changed? e.g. when on battery, use trivial, when on AC use <whatever>.
It would be relatively easy to create a module that did that I believe...
Col
On Wed, 14.04.10 15:56, Wu Fengguang (fengguang.wu@intel.com) wrote:
Hi Lennart,
We found that pulseaudio eats CPU ~19% CPU time, a little more than mplayer when playing video. This is horrible for laptop batteries.
This is not a particularly useful report.
You know, this can have so many different reasons, the only thing I can really say, is that you can rest assured that it is not supposed to eat that much in normal use.
The CPU usage of PA is primarily dependant of the latency requested by the clients. Low latency means high CPU load. Lower latency means higher CPU load. Try "pacmd list-sink-inputs" to figure out the latency the various applications requested.
Then there can be driver problems, where the timing information is not entirely correct that ALSA passes on to, with the result that we get dropouts where we shouldn't, with the results that we shorten our sleep times, with the final effect that the CPU usage goes up.
Of course, if PA is used resampling and suchlike is moved from the clients into the sound server and hence will be added to its CPU usage. And PA uses a better resampler by default than ALSA traditionally did, hence the CPU use will be a bit higher than plain ALSA.
And then of course, the CPU usage depends on the CPU used. Is this some embedded hardware?
In summary: if you want to know what is going on, you need a suitable tool, like a profiler and do the dirty work to figure out what is going on. Just saying "19%" is not helpful to figure out what is going on.
On my machine here it uses 3% CPU while playing.
Can we make it just work -- in green CPU mode?
Yes, sure. If you use "pacat" you can play audio with almost zero CPU usage, because it is one of the few clients that actually asks for sensible latency (2s), which allows us to minimize the wakeup intervals to less than a second.
I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
Fix? Where?
Lennart
On Sun, Apr 18, 2010 at 11:28 PM, Lennart Poettering mznyfn@0pointer.de wrote:
On Wed, 14.04.10 15:56, Wu Fengguang (fengguang.wu@intel.com) wrote:
I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
Fix? Where?
Sigh, another drivel of a bug report with a mis-summary. It really ought to be "For Ubuntu 9.04, the sampler was changed to X". (Note that it's speex-float-1 in 9.10 and newer.) I have seen plenty of bugs in hardware, some of which can be worked around in the driver -- for these I've been pushing patches here and to stable@ -- but, like Lennart suggests, these are by no means *caused* by PulseAudio.
Best, -Dan
2010/4/19 Daniel Chen seven.steps@gmail.com
but, like Lennart suggests, these are by no means *caused* by PulseAudio.
Best, -Dan
There are other factor affecting CPU usage significantly
1) the number of pulseaudio clients connected to PA server (i.e. number of audio stream need to be mixed ) 2) the accuracy of system timer and the clock of the sound chip 3) the latency requirement of the different PA clients 4) the resampling method 5) the cpu loading of the system 6) the period time/period size selected by PA server to configure the alsa driver
why do you ruled out the cause ?
If you use "pacat" you can play audio with almost zero CPU
usage
do you get the zero CPU usage in Ubuntu 9.04/Ubuntu 9.10 with pacat on your machines ?
'Twas brillig, and Raymond Yau at 21/04/10 01:30 did gyre and gimble:
2010/4/19 Daniel Chen seven.steps@gmail.com
but, like Lennart suggests, these are by no means *caused* by PulseAudio.
Best, -Dan
There are other factor affecting CPU usage significantly
- the number of pulseaudio clients connected to PA server (i.e. number of
audio stream need to be mixed ) 2) the accuracy of system timer and the clock of the sound chip 3) the latency requirement of the different PA clients 4) the resampling method 5) the cpu loading of the system 6) the period time/period size selected by PA server to configure the alsa driver
why do you ruled out the cause ?
If you use "pacat" you can play audio with almost zero CPU
usage
do you get the zero CPU usage in Ubuntu 9.04/Ubuntu 9.10 with pacat on your machines ?
The pacat support for proper latency adjustment is only available in more recent PA versions (with some , so chances are the older distros wont have them (although I believe a 9.10 version of 0.9.21+stable-queue exists somewhere.
These commits from stable-queue are certainly needed:
commit 19fa81bf1375032cb1a27c7715a28a52b238d4cb Author: Lennart Poettering lennart@poettering.net Date: Thu Feb 18 01:54:51 2010 +0100
pacat: always fully fulfill write requests
Make sure we always fulfill write requests from the server. If we don't the server won't ask us again and playback will stay stuck.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006611....
and this one (although it's not problematic for playback):
commit b2e9fb6f6e12a3eab8a41c67017507e60d616e2a Author: Lennart Poettering lennart@poettering.net Date: Sun Feb 21 21:09:26 2010 +0100
pacat: pass buffer_attr to recording streams too
Pointed out by Colin Guthrie.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006698....
2010/4/21 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 21/04/10 01:30 did gyre and gimble:
2010/4/19 Daniel Chen seven.steps@gmail.com
but, like Lennart suggests, these are by no means *caused* by PulseAudio.
Best, -Dan
There are other factor affecting CPU usage significantly
- the number of pulseaudio clients connected to PA server (i.e. number
of
audio stream need to be mixed ) 2) the accuracy of system timer and the clock of the sound chip 3) the latency requirement of the different PA clients 4) the resampling method 5) the cpu loading of the system 6) the period time/period size selected by PA server to configure the
alsa
driver
why do you ruled out the cause ?
If you use "pacat" you can play audio with almost zero CPU
usage
do you get the zero CPU usage in Ubuntu 9.04/Ubuntu 9.10 with pacat on
your
machines ?
The pacat support for proper latency adjustment is only available in more recent PA versions (with some , so chances are the older distros wont have them (although I believe a 9.10 version of 0.9.21+stable-queue exists somewhere.
These commits from stable-queue are certainly needed:
commit 19fa81bf1375032cb1a27c7715a28a52b238d4cb Author: Lennart Poettering lennart@poettering.net Date: Thu Feb 18 01:54:51 2010 +0100
pacat: always fully fulfill write requests
Make sure we always fulfill write requests from the server. If we don't the server won't ask us again and playback will stay stuck.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006611....
and this one (although it's not problematic for playback):
commit b2e9fb6f6e12a3eab8a41c67017507e60d616e2a Author: Lennart Poettering lennart@poettering.net Date: Sun Feb 21 21:09:26 2010 +0100
pacat: pass buffer_attr to recording streams too
Pointed out by Colin Guthrie.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006698....
--
Colin Guthrie
is it possible to provide some figure to compare the CPU usage of PA when using pacat, paplay and aplay on your machine ?
the problem of Shuang He seem related to upmixing of stereo to surround71
sink: 0 <alsa_output.pci-0000_00_1b.0.
analog-surround-71> volume: 0: 100% 1: 100% 0: 0.00 dB 1: 0.00 dB balance 0.00 muted: no current latency: 444.25 ms requested latency: 31.25 ms sample spec: s16le 2ch 48000Hz channel map: front-left,front-right Stereo resample method: speex-float-3 module: 8 client: 7 <ALSA plug-in [mplayer_2010_0414]>
'Twas brillig, and Raymond Yau at 22/04/10 02:11 did gyre and gimble:
is it possible to provide some figure to compare the CPU usage of PA when using pacat, paplay and aplay on your machine ?
the problem of Shuang He seem related to upmixing of stereo to surround71
sink: 0 <alsa_output.pci-0000_00_1b.0.analog-surround-71> volume: 0: 100% 1: 100% 0: 0.00 dB 1: 0.00 dB balance 0.00 muted: no current latency: 444.25 ms requested latency: 31.25 ms sample spec: s16le 2ch 48000Hz channel map: front-left,front-right Stereo resample method: speex-float-3 module: 8 client: 7 <ALSA plug-in [mplayer_2010_0414]>
Probably not meaninfully on this machine as it's only got stereo. I'll try and get one of my more elaborate machines ready for an upmixing comparison.
Col
On 2010-4-19 11:28, Lennart Poettering wrote:
On Wed, 14.04.10 15:56, Wu Fengguang (fengguang.wu@intel.com) wrote:
Hi Lennart,
We found that pulseaudio eats CPU ~19% CPU time, a little more than mplayer when playing video. This is horrible for laptop batteries.
This is not a particularly useful report.
You know, this can have so many different reasons, the only thing I can really say, is that you can rest assured that it is not supposed to eat that much in normal use.
The CPU usage of PA is primarily dependant of the latency requested by the clients. Low latency means high CPU load. Lower latency means higher CPU load. Try "pacmd list-sink-inputs" to figure out the latency the various applications requested.
This is the output from "pacmd list-sink-inputs", when I'm playing the video Welcome to PulseAudio! Use "help" for usage information.
1 sink input(s) available.
index: 0 driver: <protocol-native.c> flags: state: RUNNING sink: 0 <alsa_output.pci-0000_00_1b.0.analog-surround-71> volume: 0: 100% 1: 100% 0: 0.00 dB 1: 0.00 dB balance 0.00 muted: no current latency: 444.25 ms requested latency: 31.25 ms sample spec: s16le 2ch 48000Hz channel map: front-left,front-right Stereo resample method: speex-float-3 module: 8 client: 7 <ALSA plug-in [mplayer_2010_0414]> properties: media.name = "ALSA Playback" application.name = "ALSA plug-in [mplayer_2010_0414]" native-protocol.peer = "UNIX socket client" native-protocol.version = "16" application.process.id = "2901" application.process.user = "root" application.process.host = "x-shuang" application.process.binary = "mplayer_2010_0414" application.language = "C" window.x11.display = ":0.0" application.process.machine_id = "9c81eadc677bd3522a68b7984ba753 08" module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [mplayer_2010_0414]"
Thanks --Shuang
Then there can be driver problems, where the timing information is not entirely correct that ALSA passes on to, with the result that we get dropouts where we shouldn't, with the results that we shorten our sleep times, with the final effect that the CPU usage goes up.
Of course, if PA is used resampling and suchlike is moved from the clients into the sound server and hence will be added to its CPU usage. And PA uses a better resampler by default than ALSA traditionally did, hence the CPU use will be a bit higher than plain ALSA.
And then of course, the CPU usage depends on the CPU used. Is this some embedded hardware?
In summary: if you want to know what is going on, you need a suitable tool, like a profiler and do the dirty work to figure out what is going on. Just saying "19%" is not helpful to figure out what is going on.
On my machine here it uses 3% CPU while playing.
Can we make it just work -- in green CPU mode?
Yes, sure. If you use "pacat" you can play audio with almost zero CPU usage, because it is one of the few clients that actually asks for sensible latency (2s), which allows us to minimize the wakeup intervals to less than a second.
I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
Fix? Where?
Lennart
On Mon, 19.04.10 13:20, Shuang He (shuang.he@intel.com) wrote:
Please stop the cross-posting.
current latency: 444.25 ms requested latency: 31.25 ms
So, this is interesting: the client requested 30ms (which is needlessly low, but that's another question), but the server ended up providing only 444 ms! That is incredibly high and points to the fact that PA probably ran into quite a few dropouts before this, presumably due to incorrect timing or suchlike, and hence bumped up the minimal latency all the time, and bumped down the sleeping time, hence eincreasing the CPU load. Almost certainly your audio driver is at fault here.
Check syslog for any comments about that.
Lennart
2010/4/19 Lennart Poettering mznyfn@0pointer.de
On Mon, 19.04.10 13:20, Shuang He (shuang.he@intel.com) wrote:
Please stop the cross-posting.
current latency: 444.25 ms requested latency: 31.25 msSo, this is interesting: the client requested 30ms (which is needlessly low, but that's another question), but the server ended up providing only 444 ms! That is incredibly high and points to the fact that PA probably ran into quite a few dropouts before this, presumably due to incorrect timing or suchlike, and hence bumped up the minimal latency all the time, and bumped down the sleeping time, hence eincreasing the CPU load. Almost certainly your audio driver is at fault here.
Check syslog for any comments about that.
Lennart
when using -ao oss or -ao alsa , mplayer use 16 fragments and use 0.5 second for the buffer time . about 31.25ms period time is quite normal
for hda driver which has a constraint of period size must be multiple of 128 bytes ( pcie brust size ) ,
cat /proc/asound/card0/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 1024 buffer_size: 16384
In his case , mplayer is using alsa-pulse plugin and pulse device has no specific constraint on hw_params , so 31.25 ms is normal since PA did not reject the 0.5 seconds and 16 periods
since mplayer is no using pulse api , of course it will not adjust the latency since pulse device is emulate an alsa hardware device
2010/4/19 Lennart Poettering mznyfn@0pointer.de
On Wed, 14.04.10 15:56, Wu Fengguang (fengguang.wu@intel.com) wrote:
Hi Lennart,
We found that pulseaudio eats CPU ~19% CPU time, a little more than mplayer when playing video. This is horrible for laptop batteries.
This is not a particularly useful report.
You know, this can have so many different reasons, the only thing I can really say, is that you can rest assured that it is not supposed to eat that much in normal use.
The CPU usage of PA is primarily dependant of the latency requested by the clients. Low latency means high CPU load. Lower latency means higher CPU load. Try "pacmd list-sink-inputs" to figure out the latency the various applications requested.
Then there can be driver problems, where the timing information is not entirely correct that ALSA passes on to, with the result that we get dropouts where we shouldn't, with the results that we shorten our sleep times, with the final effect that the CPU usage goes up.
Of course, if PA is used resampling and suchlike is moved from the clients into the sound server and hence will be added to its CPU usage. And PA uses a better resampler by default than ALSA traditionally did, hence the CPU use will be a bit higher than plain ALSA.
And then of course, the CPU usage depends on the CPU used. Is this some embedded hardware?
In summary: if you want to know what is going on, you need a suitable tool, like a profiler and do the dirty work to figure out what is going on. Just saying "19%" is not helpful to figure out what is going on.
On my machine here it uses 3% CPU while playing.
Can we make it just work -- in green CPU mode?
Yes, sure. If you use "pacat" you can play audio with almost zero CPU usage, because it is one of the few clients that actually asks for sensible latency (2s), which allows us to minimize the wakeup intervals to less than a second.
I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
Fix? Where?
Lennart
AFAIK , the CPU usage increase with the number of applications connected to PA server .
If I run 4 instances of mplayer on Fedora 10 , the CPU usage will increase from 3% to 12%
2010/4/19 Lennart Poettering mznyfn@0pointer.de
Yes, sure. If you use "pacat" you can play audio with almost zero CPU usage, because it is one of the few clients that actually asks for sensible latency (2s), which allows us to minimize the wakeup intervals to less than a second.
Lennart
Just test it on Fedora 10
CPU usage of pulseuadio is above 3% when using pacat
CPU usage of pulseaudio is below 2% when using aplay
CPU usage of pulseaudio is below 3% when using paplay
the test audio is stereo 44100Hz pcm wav
Do you have any figures on Fedora 12 or 13 ?
participants (6)
-
Colin Guthrie -
Daniel Chen -
Lennart Poettering -
Raymond Yau -
Shuang He -
Wu Fengguang