[PD] Android latency status?

Simon Wise simonzwise at gmail.com
Fri Aug 8 12:24:02 CEST 2014


On 08/08/14 19:09, Bektur wrote:
> As far as I know, there is a port of jack2 for Android:
> https://github.com/KimJeongYeon/jack2_android (has anyone tried building it
> btw?)
>
> Not sure about latency issues, but theoretically you can route libpd in/out
> through it and try tweaking buffer size.

I have a Samsung Note (which I got mainly for the wacom pen, and it works very 
nicely in this 2014 edition at least) and have explored quite a bit ... Samsung 
seems to be using Jack as (at least part of) the back-end for the audio, but it 
is launched early by the system and I guess is used to offer the various audio 
services that are offered to apps via Java. I do not know if this is Samsung 
specific, or a more general Android thing. I'd certainly hope that if it is a 
modified version of Jack that they have the modified sources somewhere, but it 
may be just compiled and launched with their choice of available options and such.

I haven't done any non-standard modifications to the Samsung (I'll use an Udoo I 
just got, with a very similar CPU, for that). I have Debian running on the 
Samsung as a chroot, which can access anything that the user that ran the chroot 
command can do, so it is a lot easier to look around in a familiar environment. 
There is also an app that runs a decent subset of X natively on android with the 
touchscreen as input etc, so Debian can run GUI stuff as well, and pd can run 
with gui. But I have not been able to get the permissions to access the running 
jack process, or to run another one from debian. I would be able to add a single 
suid file in the appropriate directory, using the USB debug tether etc, and get 
the chroot running with root permission, but have not done that since really I 
want to know what can be done from within a normal app.

I'll explore the Udoo android next, see what it is running, and there I can shut 
down the android processes that are using devices I'd rather use via Debian, and 
can add modules if required.

>
> Bektur.
>
> On Aug 8, 2014, at 2:56 PM, 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?

The usual linux alsa device restrictions would get in the way of using devices 
directly with alsa when the android system already has them open, probably by 
the Jack that the system launched, and anyway I don't think raw devices are 
available except to root. I have not got very far, but in the samsung/android 
audio interface there are several ways to access audio. It is unlikely to help, 
since the settings for that Jack process are presumably high latency (to make 
everything nice and reliable under load).

But the alsa driver creating the device etc is part of linux, and is running on 
top of the hardware which can be controlled directly by certain libraries, which 
is what the game engines use. It would, I guess, require another audio backend 
in Pd using a suitable library for Pd to make use of this.

>>
>> 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.

certainly the latest gadgets are much much more powerful than those a year or 
two old. But this is another big issue for Pd ... they are adding power by 
adding cores, and now they are asymmetric ... my Samsung has 4 big cores and 4 
smaller ones, so there are slower cores to handle the pen etc without messing 
with the faster cores ... Linux now looks after scheduling using this 
information and Pd will not be much use on these devices without much better 
multi threading that makes use of the modern options.


Simon



More information about the Pd-list mailing list