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.
Best,
Filippo
Filippo Beck Peccoz - FBP Game Audio Production www.fbpsound.com
Studio: +49 (0)89-80033204 Fax: +49(0)89-99752164 Mobile: +49-(0)1520-4004143 Skype: fbpsound
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
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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 08/08/14 16:40, Scott R. Looney wrote:
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.
I haven't got far enough for any comparisons, but there are two ways an app can work ... accessing the standard android interfaces via Java, or in what is called native mode ... accessing the lower level C interfaces that have been enabled (in that version of Android etc), and that are accessible by the groups that the app has been assigned. Raw devices and such are not generally accessible, certainly kernel modules can't be loaded by the users or their apps, but the barrier to using the C level interfaces, openGLES and such, is only the programming effort required, not permissions for the app.
An app is assigned groups when it is downloaded, if it asks for specific permissions then the user must OK that in a dialogue, then the user that the app runs as gets added to those groups. But there is much that is root only, and not available to any group that an app can be assigned. It isn't surprising that bypassing the android Java layer gives better latencies, if you make the effort to do it properly, and especially writing the entire interface. Some libraries would be useful here.
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.
Yes, I understand Nexus (the Google hardware) are more compatible with the standard Android (which is also Google, so no surprise here) and are less aggressively locked down. Samsung uses SE Linux features to ensure the sandpit is very tightly controlled, like a corporate PC is, and have warranty fuse bits that are set if you install anything different, plus their hardware needs their in-house stuff so you would be silly to buy Samsung then disable the expensive parts. I haven't got a Nexus though, so I don't know what you lose when you relax their restrictions. Certainly you can still add most of the Google binary stuff (google play, google maps etc) to any android system, but they are not open source and linking to them would depend on what you wanted to do, and some require further agreements before linking I think.
Simon
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?
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.
best, scott
On Fri, Aug 8, 2014 at 1:33 AM, Simon Wise simonzwise@gmail.com wrote:
On 08/08/14 16:40, Scott R. Looney wrote:
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.
I haven't got far enough for any comparisons, but there are two ways an app can work ... accessing the standard android interfaces via Java, or in what is called native mode ... accessing the lower level C interfaces that have been enabled (in that version of Android etc), and that are accessible by the groups that the app has been assigned. Raw devices and such are not generally accessible, certainly kernel modules can't be loaded by the users or their apps, but the barrier to using the C level interfaces, openGLES and such, is only the programming effort required, not permissions for the app.
An app is assigned groups when it is downloaded, if it asks for specific permissions then the user must OK that in a dialogue, then the user that the app runs as gets added to those groups. But there is much that is root only, and not available to any group that an app can be assigned. It isn't surprising that bypassing the android Java layer gives better latencies, if you make the effort to do it properly, and especially writing the entire interface. Some libraries would be useful here.
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.
Yes, I understand Nexus (the Google hardware) are more compatible with the standard Android (which is also Google, so no surprise here) and are less aggressively locked down. Samsung uses SE Linux features to ensure the sandpit is very tightly controlled, like a corporate PC is, and have warranty fuse bits that are set if you install anything different, plus their hardware needs their in-house stuff so you would be silly to buy Samsung then disable the expensive parts. I haven't got a Nexus though, so I don't know what you lose when you relax their restrictions. Certainly you can still add most of the Google binary stuff (google play, google maps etc) to any android system, but they are not open source and linking to them would depend on what you wanted to do, and some require further agreements before linking I think.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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.
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?
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.
best, scott
On Fri, Aug 8, 2014 at 1:33 AM, Simon Wise simonzwise@gmail.com wrote: On 08/08/14 16:40, Scott R. Looney wrote: 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.
I haven't got far enough for any comparisons, but there are two ways an app can work ... accessing the standard android interfaces via Java, or in what is called native mode ... accessing the lower level C interfaces that have been enabled (in that version of Android etc), and that are accessible by the groups that the app has been assigned. Raw devices and such are not generally accessible, certainly kernel modules can't be loaded by the users or their apps, but the barrier to using the C level interfaces, openGLES and such, is only the programming effort required, not permissions for the app.
An app is assigned groups when it is downloaded, if it asks for specific permissions then the user must OK that in a dialogue, then the user that the app runs as gets added to those groups. But there is much that is root only, and not available to any group that an app can be assigned. It isn't surprising that bypassing the android Java layer gives better latencies, if you make the effort to do it properly, and especially writing the entire interface. Some libraries would be useful here.
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.
Yes, I understand Nexus (the Google hardware) are more compatible with the standard Android (which is also Google, so no surprise here) and are less aggressively locked down. Samsung uses SE Linux features to ensure the sandpit is very tightly controlled, like a corporate PC is, and have warranty fuse bits that are set if you install anything different, plus their hardware needs their in-house stuff so you would be silly to buy Samsung then disable the expensive parts. I haven't got a Nexus though, so I don't know what you lose when you relax their restrictions. Certainly you can still add most of the Google binary stuff (google play, google maps etc) to any android system, but they are not open source and linking to them would depend on what you wanted to do, and some require further agreements before linking I think.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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. Looneyscottrlooney@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
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-...
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@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. Looneyscottrlooney@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
I'm not sure that I am the best person to chime in here, so I'm CC'ing Peter Brinkmann, the main dude behind libpd and the android wrappers.
On Fri, Aug 8, 2014 at 10:56 AM, 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?
libpd provides both routes - it will use OpenSL ES if available on the device, or java + jni if you are on some old piece of junk. It will also use the low latency settings if you are one of the select few devices that have been blessed with this option. Still, none of the routes provide latency that is ideal for real time audio applications.
AFAIK, the root of the latency comes from within the kernel's audio drivers, so you don't gain a huge amount with OpenSL alone. I'm not sure if things have changed with the introduction of ART (dalvik replacement), or if it matters...
cheers, Rich
Like Rich said, libpd uses OpenSL ES if available and falls back on the Java API if necessary (Android 2.2 and earlier).
Internally, libpd uses the opensl_stream library ( https://github.com/nettoyeurny/opensl_stream), which hides the complexity of OpenSL and provides a few other benefits, such as a credible illusion of synchronized input and output. When configured correctly, opensl_stream will use the low-latency track of OpenSL.
You may also want to take a look at Patchfield ( https://github.com/google/patchfield), which sits on top of opensl_stream and also integrates with libpd.
Both opensl_stream and Patchfield target official APIs on stock Android devices, but they are intended to give the best possible performance within those constraints. Cheers, Peter
On Fri, Aug 8, 2014 at 12:10 PM, Rich E reakinator@gmail.com wrote:
I'm not sure that I am the best person to chime in here, so I'm CC'ing Peter Brinkmann, the main dude behind libpd and the android wrappers.
On Fri, Aug 8, 2014 at 10:56 AM, 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?
libpd provides both routes - it will use OpenSL ES if available on the device, or java + jni if you are on some old piece of junk. It will also use the low latency settings if you are one of the select few devices that have been blessed with this option. Still, none of the routes provide latency that is ideal for real time audio applications.
AFAIK, the root of the latency comes from within the kernel's audio drivers, so you don't gain a huge amount with OpenSL alone. I'm not sure if things have changed with the introduction of ART (dalvik replacement), or if it matters...
cheers, Rich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2014 07:17 PM, 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 http://puredata.info/docs/AndroidLatency/ and the numbers are staggering…
I think the figures of that list are okay to compare the devices relative to each other, but not okay in their absolute numbers. I vaguely remember Martin Schied claiming that there is some false assumption or vastly improvable implementation in the way the latency is tested there. Martin, can you remind me what that was?
Chipping in to thank you for all these helpful and interesting replies.
I'm not an Android User, but doesn't this mean that there aren't any music application for Android? With this type of latency, any rhythm based game or app seems absolutely impossible..
Thank you all!
Filippo
Filippo Beck Peccoz Game Audio
www.fbpsound.com Twitter: @fbpsound Skype: fbpsound Mobile: +49-(0)1520-4004143 Studio: +49-(0)89-80033204 Fax: +49-(0)89-99752164
On Aug 8, 2014, at 2:37 PM, Max abonnements@revolwear.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2014 07:17 PM, 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 http://puredata.info/docs/AndroidLatency/ and the numbers are staggering…
I think the figures of that list are okay to compare the devices relative to each other, but not okay in their absolute numbers. I vaguely remember Martin Schied claiming that there is some false assumption or vastly improvable implementation in the way the latency is tested there. Martin, can you remind me what that was?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlPkxKAACgkQ3EB7kzgMM6I7DACggnyAwFsFl4BOqEx0y83YyRYV fUIAninEMRElgYYbhu6QIa8lffW3L/WJ =R4tu -----END PGP SIGNATURE-----
Hi Max,
On 08/08/2014 02:37 PM, Max wrote:
On 08/06/2014 07:17 PM, 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 http://puredata.info/docs/AndroidLatency/ and the numbers are staggering…
I think the figures of that list are okay to compare the devices relative to each other, but not okay in their absolute numbers. I vaguely remember Martin Schied claiming that there is some false assumption or vastly improvable implementation in the way the latency is tested there. Martin, can you remind me what that was?
yes the latency tester on the above linked page is compiled with a too old libpd to give comparable results on higher android versions and newer versions of libpd.
As far as I remember I tested latency on some devices with the latency tester app. Then I also used the pd patch that comes with it and used it inside the most recent version of the "scene player" app (used the git version supplied with libpd, roughly 1.5 years ago). The results were different from each other, I think this is because the more recent scene player could take advantage of the newer audio API that supports lower latency. Still also with the most recent scene player back then I got nothing better than about 400 or 500ms on a device that's supposed to use low latency (Nexus i9250) - but I did not read through the code, maybe the low latency part was just not enabled - still it was faster than the latency tester app...
https://github.com/libpd/pd-for-android/wiki/Low-latency-support-for-complia...
Martin
-
Bektur -
Filippo Beck Peccoz -
Martin Schied -
Max -
Peter Brinkmann -
Rich E -
Scott R. Looney -
Simon Wise