[PD] Android latency status?

Scott R. Looney scottrlooney at gmail.com
Fri Aug 8 08:40:18 CEST 2014


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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140807/8e30af4b/attachment-0001.html>


More information about the Pd-list mailing list