<div dir="ltr">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.<br><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Aug 8, 2014 at 10:56 AM, Scott R. Looney <span dir="ltr"><<a href="mailto:scottrlooney@gmail.com" target="_blank">scottrlooney@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">This is extremely informative, Simon, and confirms much of the two sided situation i've seen in Android as far as latency is concerned.<div><br></div><div>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?</div>

<div><br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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...</div>
<div><br></div><div>cheers,</div><div>Rich</div></div></div></div>