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

[David Henningsson]

On 2010-12-12 22:01, David Henningsson wrote:
> On 2010-12-10 16:37, pl bossart wrote:
>>>>> 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
>>
>
> Hmm, I enabled gstreamer debugging and spotted this (this is from an ogg
> file playback in totem):
>
> pulsesink.c:718:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> tlength:   70560
> pulsesink.c:719:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> maxlength: -1
> pulsesink.c:720:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> prebuf:    0
> pulsesink.c:721:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> minreq:    3528
>
> So tlength is actually reasonable. This means we have a segsize of 3528
> and a segtotal of 20, then look at this code in gst_pulseringbuffer_commit:
>
>       /* Only ever write segsize bytes at once. This will
>        * also limit the PA shm buffer to segsize
>        */
>       if (towrite>  buf->spec.segsize)
>         towrite = buf->spec.segsize;
>
> ...I'm not sure whether it is the segtotal=20 that's unreasonable, or if
> these lines are the offending ones, but the combination is actually
> causing gstreamer to send 20 small packets instead of one big packet =>
> unnecessary overhead (and PA rewinds if we're not enough ahead).
>
> I tried changing "buf->spec.segsize" into "bufsize" (i e segsize *
> segtotal) and it started writing 8192 bytes at a time instead of 3528,
> which is slightly better, but still way far from tlength (or tlength/2,
> tlength/4, or whatever is an optimal number of segments).
>

Hi Pierre and rest of gstreamer-devel,

Given the discussion above, did you have any time to do more thinking 
about it? I'm attaching a simple patch. Some testing of that patch 
hasn't reported any regressions, and it does start to send larger 
packages (which in turn saves PA from additional packet overhead).
I'm attaching a patch for Ubuntu, but given that I give you a proper git 
header etc to that patch, would the folks here apply it?

// David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-buffer-size.patch
Type: text/x-patch
Size: 2024 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110110/6faf4666/attachment.bin>