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

[Felipe Contreras]

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.

> Anything in practice where this is a problem?

Yeah, I mentioned my findings in this thread in gst-devel which you
participated on:
http://article.gmane.org/gmane.comp.video.gstreamer.devel/27071

> >From the improvements from switching from pulsesrc to alsasrc and then
> some more when using a faster encoder, as stated above, your comment
> needs some more explanation, IMO.

Nobody is saying that GStreamer is the _only_ problem. In fact,
pulseaudio has similar problems with big buffers, and of course
improving the performance of the decoder will increase performance in
overall.

Just look at the numbers Halley provided:

=== audio only + fakesink
gst-launch alsasrc ! audio/x-raw-int, rate=8000 ! queue ! fakesink
gst-launch 51%CPU, pulseaudio 13%CPU

=== arecord and drop data
arecord >/dev/null
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
arecord 4.3%, pulseaudio 2.2%

Same ALSA device, same audio settings (so it's what Jan said has no
effect). My guess is that the multiple thread contexts are trashing
the performance and that can be easily checked with strace looking for
sys_futex calls. Another prediction is that removing the queue would
help drastically, or keep the queue but increase the rate to 48000
and/or the buffer-time. Finally, but somewhat unrelated, is that
fakesink performs horrendously on embedded platforms, so filesink
location=/dev/null might be slightly more neutral.

Cheers.

-- 
Felipe Contreras