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

[Stefan Kost]

Am 10.12.2010 17:37, schrieb 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

We could consider tweaking the settings on the high-level bins. I mean after all
playbin2 is used for playback of media, so it could select a high latency (at
least a higher default). Imho farsight would alreday set a low latency on the
pulsesrc/sink.

Stefan