[gst-devel] How to decrease CPU consumation for audio recording?

[Wim Taymans]

On Thu, 2010-10-07 at 03:08 +0300, Felipe Contreras wrote:
> On Tue, Jan 5, 2010 at 12:40 PM, Felipe Contreras
> <felipe.contreras at gmail.com> wrote:
> > On Thu, Dec 24, 2009 at 7:52 PM, Wim Taymans <wim.taymans at gmail.com> wrote:
> >> On Thu, 2009-12-24 at 19:13 +0200, Felipe Contreras wrote:
> >>>
> >>> GStreamer is not good at handling very small buffers.
> >>
> >> What do you mean with this?
> >
> > I mean what I said: the smaller the buffers, the worst GStreamer
> > handles them. My gut feeling is that performance would deteriorate in
> > exponential manner, and would be more noticeable in embedded
> > platforms, and specially with a single core.
> >
> >> What do you define as a small buffer? How is
> >> it not good?
> >
> > Huh? I would need to write a test application that measures
> > performance passing buffers of different sizes along multiple thread
> > contexts and plot the result in order to define that.
> 
> There you go:
> http://felipec.wordpress.com/2010/10/07/gstreamer-embedded-and-low-latency-are-a-bad-combination/
> 
> Is it clear now that GStreamer is bad at handling very small buffers?
> 

Not really. What you are trying to say is that when you push more
buffers per second, CPU consumption is higher. That's expected but not
necessarily as bad as those overly dramatic graphs suggest.

It sounds like when you mean size, you really mean duration and thus the
amount of buffers per second.

GStreamer is not designed to pass around 1 sample per buffer (that would
be typically 48000 buffers per second), you can do it but it will incur
a higher overhead that increases with the amount of elements in the
pipeline. 

GStreamer is however designed for more realistic buffer durations of
10ms (that's 100 buffers per second). The overhead that GStreamer causes
in these types of pipelines depends on a lot of things, but in well
designed pipelines you typically see overhead values of around 1% or
less (callgrind and kcachegrind are good tools to measure this).

Your comments about queue are correct. Queue is really causing a lot of
contention on mutexes (it is written as a simply fifo with mutexes). If
you use very small queue sizes, you practically force the scheduler to
do a context switch for each buffer. Again, the more buffers per second,
the more overhead it causes all over the place. For realistic use cases
of a couple of 100 buffers per second and realistic buffer sizes, this
should all perform with reasonably small overhead. That said, queue can
be improved in many ways (add a batch mode, use a lockless queue, ...)

As a datapoint: On my desktop I can push around 700000 buffers per
second, and that's then using 100% CPU (and also 100% gstreamer
overhead). (gst-launch fakesrc num-buffers=7000000 silent=1 ! fakesink
silent=1 takes about 10 seconds).

Regards,
Wim