Like Rich said, libpd uses OpenSL ES if available and falls back on the Java API if necessary (Android 2.2 and earlier).
Internally, libpd uses the opensl_stream library ( https://github.com/nettoyeurny/opensl_stream), which hides the complexity of OpenSL and provides a few other benefits, such as a credible illusion of synchronized input and output. When configured correctly, opensl_stream will use the low-latency track of OpenSL.
You may also want to take a look at Patchfield ( https://github.com/google/patchfield), which sits on top of opensl_stream and also integrates with libpd.
Both opensl_stream and Patchfield target official APIs on stock Android devices, but they are intended to give the best possible performance within those constraints. Cheers, Peter
On Fri, Aug 8, 2014 at 12:10 PM, Rich E reakinator@gmail.com wrote:
I'm not sure that I am the best person to chime in here, so I'm CC'ing Peter Brinkmann, the main dude behind libpd and the android wrappers.
On Fri, Aug 8, 2014 at 10:56 AM, Scott R. Looney scottrlooney@gmail.com wrote:
This is extremely informative, Simon, and confirms much of the two sided situation i've seen in Android as far as latency is concerned.
So, as far as we all know, libpd goes through the Java-based front door as it were. i wonder what it would take to go through the back door? is there anyone in the academic world working on low-level audio performance in Android?
libpd provides both routes - it will use OpenSL ES if available on the device, or java + jni if you are on some old piece of junk. It will also use the low latency settings if you are one of the select few devices that have been blessed with this option. Still, none of the routes provide latency that is ideal for real time audio applications.
AFAIK, the root of the latency comes from within the kernel's audio drivers, so you don't gain a huge amount with OpenSL alone. I'm not sure if things have changed with the introduction of ART (dalvik replacement), or if it matters...
cheers, Rich