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
