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