Thanks for the info! I had no idea that accessing jack on android can be this cumbersome.
So I’d probably try getting one of the latest nexus devices and repeat the latency test again. Alternatively, there’s always Android project’s source code, for instance here’s what I’ve found regarding audio:
(there are also two repos for jack, but they are empty)
I’m still interested in porting jack though, since I haven’t seen any analogues to tools like netjack for mobile devices.
Best regards,
Bektur
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@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