[pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

[pl bossart]

>>> However, the problem is quite complex and there does not seem to be one
>>> perfect fix, it's more of an optimisation problem. GStreamer in
>>> particular
>>> sends out many small data packages, and PulseAudio does not handle that
>>> very
>>> well.
>>
>> That's the default behavior, but you can cut the traffic by using the
>> latency-time property in pulsesink. This makes sure you send bigger
>> buffers, up to the 64k limit that PulseAudio has internally.
>
> Thanks, that's good to know. Now, I'm just playing a simple audio file with
> totem, so obviously we want high latency and large packet sizes, but I'm not
> a gstreamer developer - do you have an idea of what can be at fault here?
> Should totem specify a big packet size (regardless of sink?), or can we just
> change the default packet size to something big for people not requesting
> anything in particular?

The default pulsesink settings for latency/buffering are inherited
from a base class. I would agree with you that they should be large by
default and decreased explicitly when the application wants
low-latency (gaming, speech), but the opposite is done...
It's my understanding that higher-level components in the Meego/Qt
stack will specify bigger buffers/higher latencies, but for people who
use plain vanilla gstreamer optimizing for power requires a bit of
knowledge and manual configurations. This is unfortunate since every
single player will need to repeat this configuration.
-Pierre