alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Shuang He <shuang.he@intel.com>
To: Wu Fengguang <fengguang.wu@intel.com>,
	pulseaudio-discuss@mail.0pointer.de, "Fu,
	Michael" <michael.fu@intel.com>,
	alsa-devel@alsa-project.org, "Bu, Long" <long.bu@intel.com>
Subject: Re: pulseaudio eats 19% CPU power in Fedora 12
Date: Mon, 19 Apr 2010 13:20:31 +0800	[thread overview]
Message-ID: <4BCBE81F.6090606@intel.com> (raw)
In-Reply-To: <20100419032856.GA13629@tango.0pointer.de>

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

  parent reply	other threads:[~2010-04-19  5:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14  7:56 pulseaudio eats 19% CPU power in Fedora 12 Wu Fengguang
2010-04-14  8:31 ` Colin Guthrie
2010-04-19  3:28 ` Lennart Poettering
2010-04-19  3:38   ` [alsa-devel] " Daniel Chen
2010-04-21  0:30     ` Raymond Yau
2010-04-21  7:57       ` Colin Guthrie
2010-04-22  1:11         ` Raymond Yau
2010-04-22  7:53           ` Colin Guthrie
2010-04-19  5:20   ` Shuang He [this message]
2010-04-19 14:48     ` [pulseaudio-discuss] " Lennart Poettering
2010-04-20  3:30       ` Raymond Yau
2010-04-19  8:34   ` Raymond Yau
2010-04-20  5:36   ` Raymond Yau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BCBE81F.6090606@intel.com \
    --to=shuang.he@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=fengguang.wu@intel.com \
    --cc=long.bu@intel.com \
    --cc=michael.fu@intel.com \
    --cc=pulseaudio-discuss@mail.0pointer.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).