[PD] Android latency status?

Bektur ph318 at yandex.ru
Fri Aug 8 13:46:03 CEST 2014


Thanks for the info! I had no idea that accessing jack on android can be this cumbersome.

Sorry I can’t offer much advice on possible workarounds, as I do mostly iOS development, but have you heard about upcoming Android update? http://liliputing.com/2014/06/google-brings-low-latency-audio-processing-to-android-l.html

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:

https://android.googlesource.com/platform/hardware/qcom/audio/
https://android.googlesource.com/platform/external/tinyalsa/
(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 Aug 8, 2014, at 4:24 PM, Simon Wise <simonzwise at gmail.com> wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140808/ae19ca51/attachment.html>


More information about the Pd-list mailing list