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?

and as far as Samsung devices go - one event that sort of turned my head around was seeing someone playing FIFA Football on a Galaxy S4. when i saw that, i started thinking if EA's releasing a game on the platform, they've gotta have found out a workaround for the latency issue enough to release a mobile title on Android. it would just be nice if workarounds like this were available to everybody.

best,

scott

 

On Fri, Aug 8, 2014 at 1:33 AM, Simon Wise <simonzwise@gmail.com> wrote:

On 08/08/14 16:40, Scott R. Looney wrote:

one quick answer to these Android latency issues - it seems that if you're
a big developer, like EA Games and such, then you can create your own audio
engines running largely independently of the Android OS and solve most of
the issues that way.

I haven't got far enough for any comparisons, but there are two ways an app can work ... accessing the standard android interfaces via Java, or in what is called native mode ... accessing the lower level C interfaces that have been enabled (in that version of Android etc), and that are accessible by the groups that the app has been assigned. Raw devices and such are not generally accessible, certainly kernel modules can't be loaded by the users or their apps, but the barrier to using the C level interfaces, openGLES and such, is only the programming effort required, not permissions for the app.

An app is assigned groups when it is downloaded, if it asks for specific permissions then the user must OK that in a dialogue, then the user that the app runs as gets added to those groups. But there is much that is root only, and not available to any group that an app can be assigned. It isn't surprising that bypassing the android Java layer gives better latencies, if you make the effort to do it properly, and especially writing the entire interface. Some libraries would be useful here.

however, if you're a smaller developer working within Android's audio
system, you're stuck with latency, although for a small number of devices
(mainly the Nexus devices) the delay time was improved in Jelly Bean. this
performance may have improved lately, or at least more devices seem to
respond better. it's still nowhere near the responsiveness of iOS.

Yes, I understand Nexus (the Google hardware) are more compatible with the standard Android (which is also Google, so no surprise here) and are less aggressively locked down. Samsung uses SE Linux features to ensure the sandpit is very tightly controlled, like a corporate PC is, and have warranty fuse bits that are set if you install anything different, plus their hardware needs their in-house stuff so you would be silly to buy Samsung then disable the expensive parts. I haven't got a Nexus though, so I don't know what you lose when you relax their restrictions. Certainly you can still add most of the Google binary stuff (google play, google maps etc) to any android system, but they are not open source and linking to them would depend on what you wanted to do, and some require further agreements before linking I think.

Simon

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list