Am 10.12.2010 17:37, schrieb pl bossart: >>>> 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 We could consider tweaking the settings on the high-level bins. I mean after all playbin2 is used for playback of media, so it could select a high latency (at least a higher default). Imho farsight would alreday set a low latency on the pulsesrc/sink. Stefan
