Well, the JNI means you get to run native code. For something like this, I think that's actually a requisite. My reasoning would be
a) This is real-time and could potentially be disrupted by GC pauses
b) JNI means you get to use OpenSL, the best and lowest latency sound engine on Android
c) This builds on top of libquiet, a C library, which itself builds on liquid dsp, another C library. Rewriting these in Java would be significantly more work than building the JNI wrapper. Especially true for liquid which is a mature library with lots of code
a) This is real-time and could potentially be disrupted by GC pauses
b) JNI means you get to use OpenSL, the best and lowest latency sound engine on Android
c) This builds on top of libquiet, a C library, which itself builds on liquid dsp, another C library. Rewriting these in Java would be significantly more work than building the JNI wrapper. Especially true for liquid which is a mature library with lots of code