[gst-devel] pulsesink optimizations

[Felipe Contreras]

On Fri, Oct 16, 2009 at 12:21 AM, pl bossart <bossart.nospam at gmail.com> wrote:
>>> 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.

Currently playbin2 adds a queue between the decoder and the sink, so
they run in different threads, and the thread synchronization will
result in more overhead with smaller buffers (not to mention buffer
creation/destruction). So from GStreamer point of view, there's a
direct relationship between buffer size and CPU overhead. I'm not sure
if "too big buffers" would actually impact negatively PA, but my guess
is there's a limit to how big the buffer should be, and that would
actually be the ideal one.

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

That is true. I haven't thought about the video case, from my point of
view audio-only playback is already too screwed up to think about
that. What's the worst that could happen? A temporary A/V
synchronization miss-match when the video decoder lags behind?

-- 
Felipe Contreras