pulseaudio eats 19% CPU power in Fedora 12

pulseaudio eats 19% CPU power in Fedora 12

[Wu Fengguang]

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

Re: pulseaudio eats 19% CPU power in Fedora 12

[Colin Guthrie]

'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

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: pulseaudio eats 19% CPU power in Fedora 12

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12

[Daniel Chen]

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

Re: pulseaudio eats 19% CPU power in Fedora 12

[Shuang He]

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
>
>    

Re: pulseaudio eats 19% CPU power in Fedora 12

[Raymond Yau]

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%

Re: [pulseaudio-discuss] pulseaudio eats 19% CPU power in Fedora 12

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: [pulseaudio-discuss] pulseaudio eats 19% CPU power in Fedora 12

[Raymond Yau]

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 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
>
>
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

Re: pulseaudio eats 19% CPU power in Fedora 12

[Raymond Yau]

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 ?

Re: pulseaudio eats 19% CPU power in Fedora 12

[Raymond Yau]

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 ?

Re: pulseaudio eats 19% CPU power in Fedora 12

[Colin Guthrie]

'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
> 
> 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 ?

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.html


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.html






-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: pulseaudio eats 19% CPU power in Fedora 12

[Raymond Yau]

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
> >
> > 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 ?
>
> 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.html
>
>
> 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.html
>
>
> --
>
> 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]>

Re: pulseaudio eats 19% CPU power in Fedora 12

[Colin Guthrie]

'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

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]