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

[David Henningsson]

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).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic