[PD] Android latency status?

[Peter Brinkmann]

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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140809/c9f3bab9/attachment.html>