Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
On 2010-4-19 11:28, Lennart Poettering wrote: On Wed, 14.04.10 15:56, Wu Fengguang (fengguang...@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-_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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
[crossposts removed] On Mon, Apr 19, 2010 at 7:48 AM, Lennart Poettering mzn...@0pointer.de wrote: 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), I'm interested in that other question.What is a reasonable latency to request? In video games, especially ones streamed from remote servers (e.g. OnLive), latency is a huge issue; the network latency is unavoidable, so their client app is likely to be very keen to have minimal locally-caused latency. http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php suggests that gamers will start noticing if the time from pressing a button to the time they hear a sound is above 70 to 100ms. Let's say the network latency to the game server is 20ms (can't ask for much lower), and that the streaming codecs have a latency of 10ms on each end (likewise). The time from a button push to hearing a sound would then be 20ms up + 10 ms encode + 20 ms down + 10 ms decode = 60ms. That leaves all of 10 to 40 ms for local audio latency. So, in what way is requesting 30ms unreasonable in that scenario? - Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
'Twas brillig, and Dan Kegel at 19/04/10 16:53 did gyre and gimble: [crossposts removed] On Mon, Apr 19, 2010 at 7:48 AM, Lennart Poettering mzn...@0pointer.de wrote: 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), I'm interested in that other question.What is a reasonable latency to request? In video games, especially ones streamed from remote servers (e.g. OnLive), latency is a huge issue; the network latency is unavoidable, so their client app is likely to be very keen to have minimal locally-caused latency. Latency is not what you think it is. AV sync is a big issue with video playback, but latency is generally not a problem. http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php suggests that gamers will start noticing if the time from pressing a button to the time they hear a sound is above 70 to 100ms. That's different. Games require interaction. Taking an action produces an effect. With music and video playback this doesn't apply until you fast forward or rewind. With audio or video playback in an ideal world we'd be able to buffer up 10 - 20 seconds of data and then let the server deal with it. If/when some of that data is invalidated (e.g. the user fast forwards or rewinds) then that's fine, we throw it away and rewind the buffers and make our adjustments. Provided the skipping around like that is not the common case and that the amount of buffered/decoded audio is managed correctly, the power savings from this approach are significant. Have a look at: http://0pointer.de/blog/projects/pulse-glitch-free.html Let's say the network latency to the game server is 20ms (can't ask for much lower), and that the streaming codecs have a latency of 10ms on each end (likewise). The time from a button push to hearing a sound would then be 20ms up + 10 ms encode + 20 ms down + 10 ms decode = 60ms. That leaves all of 10 to 40 ms for local audio latency. So, in what way is requesting 30ms unreasonable in that scenario? I think I've covered that. The requirement for low latency itself for video playback is generally invalid. AV sync does not mean playing the video and the audio at the same time and hoping for the best. There are clear and specific ways to get synchronisation information from PA to deal with these scenarios. If you care about your application's power usage and thus battery drain, then the desire for low latency should be ditched. 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
On Mon, Apr 19, 2010 at 9:39 AM, Colin Guthrie gm...@colin.guthr.ie wrote: http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php suggests that gamers will start noticing if the time from pressing a button to the time they hear a sound is above 70 to 100ms. That's different. Games require interaction. Taking an action produces an effect. With music and video playback this doesn't apply until you fast forward or rewind. But I'm interested in the game case, specifically the remotely streamed game case. With audio or video playback in an ideal world we'd be able to buffer up 10 - 20 seconds of data But that's not possible in a game. Let's say the network latency to the game server is 20ms (can't ask for much lower), and that the streaming codecs have a latency of 10ms on each end (likewise). The time from a button push to hearing a sound would then be 20ms up + 10 ms encode + 20 ms down + 10 ms decode = 60ms. That leaves all of 10 to 40 ms for local audio latency. So, in what way is requesting 30ms unreasonable in that scenario? I think I've covered that. The requirement for low latency itself for video playback is generally invalid. AV sync does not mean playing the video and the audio at the same time and hoping for the best. There are clear and specific ways to get synchronisation information from PA to deal with these scenarios. If you care about your application's power usage and thus battery drain, then the desire for low latency should be ditched. Are you saying that one should not play remotely streamed games using pulseaudio? I'm confused. - Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
'Twas brillig, and Dan Kegel at 19/04/10 17:51 did gyre and gimble: Are you saying that one should not play remotely streamed games using pulseaudio? I'm confused. My bad, I misread your origninal post and missed the games bit of the video games phrase. I thought you started off talking about video then used games as a further example. My bad! I'll let Lennart reply as to whether or not the values are reasonable or not as I don't honestly know :p 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
On Wed, 14.04.10 15:56, Wu Fengguang (fengguang...@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 PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
On Sun, Apr 18, 2010 at 11:28 PM, Lennart Poettering mzn...@0pointer.de wrote: On Wed, 14.04.10 15:56, Wu Fengguang (fengguang...@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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
