[gst-devel] pulsesink optimizations

[Felipe Contreras]

On Thu, Oct 15, 2009 at 3:18 AM, René Stadler <mail at renestadler.de> wrote:
> pl bossart wrote:
>> That's not necessarily an option. There are 3rd party decoders out
>> there whose code is not necessarily public. And fixing the decoders is
>> somewhat odd when the real problem is the sink...
>
> The sink is not perfect, but the decoder situation also need work. Current
> decoders chose the output buffer sizes themselves, and this is wrong. Yes
> you could change the sink and stitch these buffers together using pad_alloc,
> but the fact remains that the decoder picks the size and therefore decides
> on the overhead up to the sink (and all processing elements between decoder
> and sink).
>
> This became apparent to me when Felipe profiled OggVorbis playback with a
> highly optimized decoder (ffmpeg). Basically the CPU spends an insane amount
> of time pushing GStreamer buffers around compared the actual audio decoding.
> And this on the N900, which shows exactly that the current situation is
> complete nonsense for a battery-powered device.

Indeed. I profiled the audio pipeline and 30% of the time was spent on
the decoder, the rest was spent pushing buffers around. When I
increased the buffer sizes pushed by the decoder (128k) efficiency
increases, now the time spent is 45%, but still, 55% CPU time spent
pushing buffers around is unacceptable.

Profiling what happens on pulseaudio side is an exercise I haven't
done yet, but as René said, my guess is that there's some ideal buffer
size that pulseaudio would like to receive from the decoder that's big
enough for GStreamer not to choke on it.

Removing the queue from the decoder to the sink would also help to
avoid the unnecessary overhead of mutex contention, specially on small
buffers.

Ideally I guess the sink should be able to receive small buffers
without performance penalty, but currently that doesn't seem to be
case.

Cheers.

-- 
Felipe Contreras