[pulseaudio-discuss] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
dank at kegel.com
Mon Apr 19 09:51:02 PDT 2010
On Mon, Apr 19, 2010 at 9:39 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>> 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
> 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
Are you saying that one should not play remotely streamed games using
More information about the pulseaudio-discuss