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.
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.
in both cases, however (the rich and the poor), the hardware performance and latency is likely to vary considerably between say, a blazing quad core Snapdragon and a poky dual core Rockchip processor. that's just the way things go. i would also imagine PDs code to create a certain amount of delay in addressing the hardware via ALSA through Open SL ES. i don't have any figures on that situation though.
anyway whatever else, i'm interested if folks can figure a way to start getting decent latency on Android, through whatever means.
best, scott
On Thu, Aug 7, 2014 at 10:55 PM, Simon Wise simonzwise@gmail.com wrote:
On 06/08/14 20:17, Filippo Beck Peccoz wrote:
Dear list,
I'm in the process of starting another PD based project, but was wondering if the latency on Android devices is still terrible compared to any other platform? I've seen this list and the numbers are staggering…
is there really no solution at all to this problem? Anything that need to be closer synced is basically impossible with that kind of latency :Z
Not whining of course, just curious as to why this is still a problem on Android.
perhaps because the gadgets being sold are set up for media playback, as devices where the user can buy connection to an ISP then buy downloadable media and apps through the company store, that kind of thing. Big buffers make all that smoother and more reliable. Then, partly to make sure they are plug and play, that they have a reasonable chance at offering support to naive users and those that apps and media downloaded will "just work" on whatever (cheaper or more powerful device) ... and I'd guess also partly to keep control of the platform and help keep most digital sales in house etc ... the manufacturers deliver them set up so that the user and the apps they download can only use the API that is provided and with big warnings whenever said users strays from the path. You are wishing to use them for a different purpose, with different API needs.
It is possible to install an unrestricted android OS, but the magic incantation "void the warranty" scares many away from this (so does the incessant, but vague, message of "beware of pirates"). So if your project is for devices you have control of, and warranty fuse bits are not a concern, then it is possible to try using the usual linux audio stack alongside androids user interface, and get the kind of audio latencies possible with linux on that hardware.
But ... you probably want the option of distributing more widely than that, and if you don't stick to the rules you can't distribute to devices that are restricted in the usual way, while if you want to use the devices as hardware you probably don't care to much whether it is android or GNU that is running on top of the linux kernel.
You can certainly try hardware such as the Udoo, which has full GNU- and Android- linux support, with the same quad CPU that the 2013 Samsung Note (and others) use, and with touchscreens available, considerably cheaper than a Samsung. Not in the same compact form of course, and the screen isn't as nice. For that you might try some of the tablets that sold with less restrictive setups, more admin/root access etc.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list