Costs of using the JNI on android

Question

I'm writing an application (on android) that uses both java code, and native code. Every so often, a sound will need to be played. Unfortunately, the native code doesn't have APIs (or at least stable/official ones) for audio, but only it knows when a sound needs to be played. I thought up two ways to do it:

1. Have a function that keeps track (in a queue or whatnot), of the sounds that need to be played. When called, it will return a string giving the name of the sound that needs to be played. This way, the java code could call this function until it gets an empty string, where it plays the sound.

2. Return an array of strings of the sounds that need to be played, or an empty array if none.

But then I realised that JNI calls are expensive. And these would still require the java code to call the function every iteration or so to make sure that it's playing the right thing. And especially bad for #1, as it would have to call for every sound left to play, although not too much worse I would imagine.

So, are the JNI calls too expensive to make this not feasible? Should the native code somehow inform the java code that sounds need to be played without the java code asking first (thus making less JNI calls). I did notice though that the draw code in the android opengl es 2 ndk example went through the JNI a lot, and it seemed okay, but then again, it only drew a triangle and a background.

I'm not sure how I would go about profiling this, other than making both and looking to see what works better, so I would greatly appreciate your input. Thank you very much.

Answer 1

Please take a look at NDK sample from Tegra Resources .

Android SDK & NDK sample applications and documentation (NV_EVENT, accelerometer, audio, JNI performance, OpenGL ES 2.0 and multitouch)

It includes JNI Audio sample what you want to implement. OpenGL ES 2.0 sample and JNI Performance testcode are also included.

(Besides, OpenSL ES audio API for NDK is available since Android 2.3.)