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

Felipe Contreras felipe.contreras at gmail.com
Thu Oct 7 17:39:52 CEST 2010


On Thu, Oct 7, 2010 at 3:56 AM, Gruenke, Matt <mgruenke at tycoint.com> wrote:
> If pthread_mutex_lock() is an expensive call on your system, then try
> building glib with the configure option --enable-debug=no.  When you
> build gstreamer & plugins, define G_DISABLE_CAST_CHECKS.
>
> Otherwise, you're locking mutexes every time you cast (look at
> g_type_check_instance_cast() in gobject/gtype.c).  Once you have enough
> threads doing enough of those checked casts, you should actually start
> to see lock contention and performance will degrade nonlinearly.
>
> You can also disable logging, by configuring gstreamer with the
> --disable-gst-debug option.  I'm not sure how many mutexes it involves,
> but we've found that higher logging levels can add significant overhead.

Yes, we do all that.

> BTW, it would be more instructive to plot CPU time in terms of # buffers
> (or just raw buffer throughput with a fakesrc).  Look for this to be
> linear in terms of the number of buffers, queues, and elements.  If it's
> not, then there's something interesting going on.  Otherwise, your task
> is simply to look for ways to reduce the overhead of each chain().

My speculation is that so much contention trashes the cache, that's
why the performance degrades exponentially. Anybody is welcome to
profile different things, but my findings are logical and conform to
what we have been seeing; the more locking you do, and the bigger the
mutual exclusion area, the more CPU time wasted due to contention.

-- 
Felipe Contreras




More information about the gstreamer-devel mailing list