is oboe future-proof?

[alienpenguin]

Hi all,
i have written a cross-platform c++ voip library and uses portaudio for audio interaction; on Android i am using a portaudio fork that has implemented an OpenSLES backend and it works quite nicely.
However i found out that to use Acoustic Echo Cancel i cannot use OpenSLES so i have to rewrite the backend for android, now my doubts are:

• is a c++ library like oboe the correct choice? I am wondering if google will release another set of features only available through Java APIs and i will be having the same problem as today. Obviously, nobody can predict the future but i'd like your opinion on this
• What are the current performances of OBOE vs Java? what do you think? In you experience if i go a pure JNI solution would i be impacted by latency or other issue? The rest of the library is c++ and that is not gonna change so i am wondering just how to deal with the android audio system.

Thanks for your thoughts

[philburk]

OpenSL ES has been deprecated. So it will not have any new features added.

is a c++ library like oboe the correct choice?

If you are doing native audio then we recommend using Oboe. On Android versions 8.1 or later it will use AAudio.
Oboe has a QuirksManager that provides workarounds for bugs on several devices. So it is better than using AAudio directly.

What are the current performances of OBOE vs Java?

Java is surprisingly fast but native C++ is slightly faster. And you can get lower latency using Oboe because you can get a higher priority callback thread, and can use MMAP on some devices.

Luckily Oboe/Audio API was inspired by PortAudio. The APIs are very similar. So converting your app from using PortAudio to Oboe should be very simple.