[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