Running out of horsepower

[droid_stricken]

Hi All,

This is a very generic question. Hope some of you might be able to
help me.

I have started writing an app for audio processing - FFT, RTA and
such.

I am capturing audio using AudioRecord class and filling up the input
buffer in a AsyncTask background thread.
Then, there is another thread that processes the input samples.
All of the audio processing [filtering algo and such] is done in
Native.

What i am realizing is that i am quickly running out of time. I am
only able to process 3 or 4 octave bands before i run out of time and
the input buffer overfills.

I was looking at the other apps on the market, esp from RadonSoft and
that app seems to run very smoothly on my development device.

So, wondering what's the problem i am having.
One obvious thing is that my algorithm may be inherently non-
optimized. But this algo is the same that i use on iOS platform which
runs perfectly fine without over-running the input buffers.

I tried removing the graphics altogether but still run out of time in
processing the data itself.

Any ideas are welcome.

Thanks.

[mic _]

Which Android device is this? Is it some low end device, or one where you would expect performance to be good?

If you're not doing so already, you'll probably want to use a direct buffer ( http://developer.android.com/reference/java/nio/ByteBuffer.html ) so that your native code can access it directly instead of having to do redundant memory copies. There's a method in the AudioRecord class for reading data into a direct buffer.

Another thing you might want to try is to increase the input buffer size.

And a third option, which you hopefully won't have to resort to, is to optimize your filters (read: NEON).

/Michael

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[droid_stricken]

I am using a pretty powerful device Google's Nexus One from HTC.
Thanks for the direct buffer idea. I will look into it.

/droid_stricken

On Mar 26, 3:34 pm, mic _ <micol...@gmail.com> wrote:
> Which Android device is this? Is it some low end device, or one where you
> would expect performance to be good?
>
> If you're not doing so already, you'll probably want to use a direct buffer

> (http://developer.android.com/reference/java/nio/ByteBuffer.html) so that

[a1]

My guess: you are compiling your native code for armeabi only (ARMv5TE instruction set, which means software floats). Check APP_ABI documentation.

--

Bart

> > android-ndk+unsubscribe@googlegroups.com.

[droid_stricken]

My device CPU is ARMv7 Processor. So, i used 

APP_ABI := armeabi-v7a

in my Android.mk file.

But the ndk-build is still producing a "armeabi" so file.

Any idea why?

Thanks.

[droid_stricken]

Hi mic,

The first two suggestions did not help. Also, i tried to compile against armeabi-v7a ABI but that's not happening. ndk-build is kinda ignoring my directive in Android.mk

APP_ABI := armeabi-v7a

altogether. I say this because my apk that is generated just has a .so file in folder lib/armeabi and i don't see a lib/armeabi-v7a there.

Can you tell me what the NEON is all about? That looks like my last refuge for now.

Thanks.

[Mārtiņš Možeiko]

APP_ABI variable needs to be set in Application.mk file, not Android.mk file.
Read the docs/ANDROID-MK.html and docs/APPLICATION-MK.html files more
carefully from NDK distribution.
See also samples/hello-neon example from NDK distribution to see how
it is used in Application.mk file.

--
Mārtiņš Možeiko

2012/3/30 droid_stricken <hari...@gmail.com>:

>>>> > > android-ndk...@googlegroups.com.

>>>> > > For more options, visit this group at
>>>> > >http://groups.google.com/group/android-ndk?hl=en.
>

> --
> You received this message because you are subscribed to the Google Groups
> "android-ndk" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-ndk/-/4pcddkRARIUJ.

>
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to

> android-ndk...@googlegroups.com.

[RLScott]

The APP_ABI := armeabi armeabi-v7a goes in the Application.mk file,
not the Android.mk file. Note that I included both armeabi and
armeabi-v7a. That way the app gets built with both JNI libraries and
will use whichever one is appropriate for the device the software is
installed on.

I also have an FFT app (a piano tuner) and I compute 4096-point real
FFTs in about 3 to 10 msec depending on the device. I know because
the users send me performance data my app gathers while it runs. But
some devices show as much as 66 msec. for the same calculation. I
think those devices are the ones without a v7a processor. By the way,
you don't need to go to NEON. Just get the v7a hardware floating
point working and you will be fine.

> >>> > > android-ndk...@googlegroups.com.

[RLScott]

One other item that may help you:

In my Android.mk file I have:

LOCAL_CFLAGS := -DHAVE_CONFIG_H -DFPM_ARM -ffast-math -O3 -Wall

[David Turner]

Is there a significant reason to use -ffast-math for you? Did you measure it ? Did you read http://programerror.com/2009/09/when-gccs-ffast-math-isnt/ ?

[droid_stricken]

Thanks to all of you that contributed to this thread.

Implementing the following suggestions helped me greatly i.e i see a 85% improvement in performance.

To summarize:

I added APP_ABI := all to my Application.mk file

I added LOCAL_CFLAGS := -DHAVE_CONFIG_H -DFPM_ARM -ffast-math -O3 -Wall to my Android.mk file

I avoided NEON altogether

I have a follow up question : I am using OpenSL-ES library in my native code. Unfortunately, this will work on API Level 9 or 10 and higher.

I am using OpenSL-ES to capture audio efficiently. What are my alternatives to OpenSL-ES for making my audio processing work the way it is now in native code?

Thanks

On Saturday, 31 March 2012 12:23:58 UTC-5, Digit wrote:

Is there a significant reason to use -ffast-math for you? Did you measure it ? Did you read http://programerror.com/2009/09/when-gccs-ffast-math-isnt/ ?

On Sat, Mar 31, 2012 at 4:46 PM, RLScott <fixtha...@yahoo.com> wrote:

One other item that may help you:

In my Android.mk file I have:

LOCAL_CFLAGS := -DHAVE_CONFIG_H -DFPM_ARM -ffast-math -O3 -Wall

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.

To unsubscribe from this group, send email to android-ndk+unsubscribe@googlegroups.com.