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

[Colin Guthrie]

'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 <mznyfn at 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/]