[gst-devel] strange CPU loading for audiotestsrc and filesrc

[Viraj Karandikar]

Hi,
I was able to build oprofile and get it working on DM6446.
But I am not getting consistent numbers with oprofile. For case 1, I am
getting CPU load around 12-14%, i.e 2-3% variation across runs.
Is this expected?
Also in case 1, most of the CPU is spent in gstreamer libraries
(libgstreamer-0.10.so.0.21.0, libgstbase-0.10.so.0.21.0, libpthread-0.10.so,
libgobject-2.0.so.0.2105.0, libglib-2.0.so.0.2105.0) and audiotestsrc is
taking around 0.2% of total (for silence case).

I also tried --disable-debug, --disable-gst-debug, --disable-trace
--disable-alloc-trace options while configuring the gstreamer.
With this build I got reduction of around 50% in gstreamer loading (out of
8% CPU load in one of the test case). This should help in reducing overall
system load in final application.
Thanks,
Viraj

On Tue, Oct 13, 2009 at 1:56 AM, Stefan Kost <ensonic at hora-obscura.de>wrote:

> Michael Smith schrieb:
> > On Wed, Oct 7, 2009 at 10:49 PM, Viraj Karandikar <virajk at gmail.com>
> wrote:
> >> Hi,
> >>
> >> I am seeing some strange behaviour while doing CPU load measurement when
> >> running gstreamer.
> >> I am relying on uptime and idle time give by "cat /proc/uptime" to
> calculate
> >> CPU load.
> >> We have implemented custom audio source (dalsrc) and sink (dalsink)
> plugins
> >> for our board (ARM9E on TI DM6446).
> >> I am using gstreamer-0.10.24.
> >>
> >> I have following two cases:
> >>
> >> Case 1:
> >> gst-launch audiotestsrc wave=silence is_live=true blocksize=160 !
> >>
> audio/x-raw-int,rate=8000,depth=16,channels=2,width=16,signed=\(boolean\)TRUE,endianness=\(int\)1234
> >> ! dalsink
> >> Average CPU load over 5 minutes : 18%
> >
> > As well as your cpu usage measurement technique being pretty
> > inaccurate, it's not surprising that audiotestsrc is slow - it's a
> > test element, and has has absolutely no optimisation done, or even any
> > attempt to make it vaguely ok. It's probably just doing something
> > stupid for the silence case.
>
> Well, it actually has bben optimized somewhat. Especially for silence it
> *shouldn't* do much. But anyway the only way to find out would be to run
> e.g.
> oprofile on it (its available on arm too).
>
> A slightly better version to check the load would imho be to use sync=false
> on
> the sink and run the example with time. Then see which version is finished
> earlier.
>
> Stefan
>
> >
> > Additionally, the first case is a live source - your second isn't.
> > Those aren't very directly comparable. There might be something that's
> > slower because of that.
> >
> > Mike
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>



-- 
- Viraj
Reality is merely an illusion, albeit a very persistent one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20091014/2a9908cc/attachment.htm>