[gst-devel] pulsesink optimizations

[pl bossart]

>> We could for example change the ogg demuxer to push all packets in a
>> page in a bufferlist and make the vorbisdecoder decode the complete list
>> before pushing the list of samples to the sink. This would reduce the
>> amount of objects that get pushed around between elements.
>
> I don't think that would help. What we need is to push big buffers to
> pulsesink, regardless of what we receive on the input. It's not a big
> problem for the decoder to fill some temporary buffer.

It does not help cpu- or power-wise to push buffers larger than 64k
into PulseAudio, so the 'big' buffers would be limited to ~370ms or
~14 decoded MP3 frames.
Given this upper bound, how would the decoder know how big the buffers
should really be? If somehow you don't provide the latency information
from the sink back to the decoder, the decoder is going to make
arbitrary decisions no matter what context it is used in. If you are
doing audio only, using large buffers is no issue, but if you are
using the same decoder with video active, you may want to avoid too
large buffers.