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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
