[gst-devel] pulsesink optimizations

[pl bossart]

> Note that minreq is just the threshold when pulse will ask for more data. You
> are free to send whatever amount is writable when you have data ready, it can
> be smaller or larger than minreq (pulsesink does exactly that).
<snip>
> Yes indeed, in fact the patch gives next to no CPU load improvement. However,
> it leads to the writes from gst to pa being grouped together with larger
> intervals of inactivity in between (tunable with the latency-time property).
> This grouping together results in improved power management. In the N900 I
> measured a penalty of 10% in energy consumption without the patch applied (for
> MP3 on wired headset, display off, i.e. typical long term playback use-case).

My point was that the buffer_time property is used to set the audio
latency, while the latency_time property doesn't set any latency, only
the granularity of the gstreamer processing. This is not exactly
self-explanatory without knowing in detail how PulseAudio works. To be
more consistent, we should rename these properties. In PulseAudio
pacat, the options are called --latency and --process-time, this is a
lot more intuitive than the current gstreamer options.

While I don't have qualitative data, I concur with Felipe's
observations. I have a gstreamer-based audio player running at 8-9%
CPU while a stand-alone player using the same decoding engine needs 5%
in the same conditions (no UI, etc). That's a lot of overhead...