On Wed, 29 Jun 2011, Olivier Guilyardi wrote: Agreed, but I think this particular aspect needs a little LAD input (*cough*torben*cough*). :-) I'm all about Real Time. :-) And that's the thing... we use 32-bit FP here because it's easier to program and desktop has Lots Of It. But similar algorithms can be adopted to handle S16 data and it'll have better performance on a mobile device. When I deliver a plugin... I want it to be Instant Awesome. Not, "Oh... yeah... about that: your phone sux. Not enough floating point power. Sorry. All sales are final." And this is what I'm wondering... could/should this be done with an LV2 extension? -gabriel

It can be a factor of 1000 if the binaries are built assuming there is an FPU. What happens is you get a system call for every failed float operation. If the toolset is geared to understand that none is available then it generates soft floating point operations that just occur in the user thread. Performance hit is about two zeroes less than you are discussing here. Android appears to generate softfloat code. Do these systems actually process the floats though? I would have thought most of their work was moving floating point *buffers around so that other programs could do DSP work on them - these are plugin processors so there is not a great demand that they manipulate the data they move between the plugins (LADSPA is rather unfortunately named as in does seem to suggest it does DSP which it doesn't - but I will happily stand corrected here). Moving audio data around should only affect memory alloc rather than CPU hits. If this code does floating point work then the basic stuff (mixing, moving, etc) can be accelerated on the ARM FPU. Yes, but I don't think it has to be that big. The bigger issue is why the hell would you want to do it, integrate LV2 and LADSPA on to this platform? The issue is that support on Linux is already patchy, so are the few apps that support it on Linux likely to migrate to Android? A lot of the audio apps that now appear on Andoid (very few of which come from a Linux heritage) are taking a monolithic approach of having an integral package with the synth/bass/drums/seq in the app. There probably are arguments for doing this. The actual CPU performance of the current ARM dual core handsets is pretty respectable and it is only going to increase. So as the tablets start having these resources then there are some interesting but I really think there is a difference between Linux and something like Android - this just uses a Linux kernel, most of the rest is way different. Don't you think it is more likely that people who are interested will run Linux as a replacement for Android on the ARM tablets rather than have the apps ported over? Regards, nick

[snip a load of guff...] The apps should still work with float as they would on any platform. LV2 nor LADSPA are going to add much overhead as they do not manipulate floats. Then don't do them. The apps should process floats. The ARM softfloat overhead is not that great and the coding required to get access to the GPUs is suitable that developers will implement them for optimisations. I think Android is trying to avoid wheels altogether, wheels are very old hat. Android is not Linux and you need to understand the difference between an app and an application. So are you suggesting the people who have phones, who don't want to contend with installing Linux on them, will still want to contend with trying to gets apps to interoperate with LV2 or LADSPA? Apps don't do much interoperation so you are looking at one humongous can of worms and all that for very little gain when there are ready made apps that provide a lot of that combined functionality. Linux, LV2, LADSPA, plugins, disposable audio interfaces are all for people who are up for a challenge. The app model was designed for all the hundreds of millions of handset owners who for the very, very largest part have zero interest in being confronted with this level of complexity. Why do you want to introduce it? For the tiny minority who are interested in doing this on handsets/tablets then native Linux ports are the probable attractive option. Regards, nick

No, but you are talking about getting developers to interoperate. The Android app model is very segregating so if you want to share libraries then you will also have to have all developers of each codestream to share the same signing certificates. This is what I mean about the difference between an application and and app, and opening cans of worms. Regards, nick.

On 06/29/2011 09:07 PM, Nick Copeland wrote: No, technically, an app can load a native shared library provided by another without caring about any kind of signature. An app can freely dlopen() a library provided by another app. There are great interaction/interoperability opportunities on Android. Not all mobile operating systems support this. -- Olivier

On Wed, 29 Jun 2011, Nick Copeland wrote: Yes, if this can't be overcome[1] then it defeats the purpose of a plugin system. -gabriel [1] That is, overcome without jail-breaking your device.

Hi, Reading this thread again, I feel like clarifying a few points. On 06/29/2011 10:03 PM, Nick Copeland wrote: You are confusing a real lot of things here. The APK package signature have nothing to do with accessing another package data files or libraries. I am not talking about accessing system libraries. I am talking about one application accessing the shared libraries provided by a third-party application. When an application gets installed, the Android Manager installs the libraries that it provides into the application data directory, in the lib/ subfolder. And these libraries are world readable and executable. In the past I was also puzzled by this, and thought it was risky to rely on it, but I discussed this many times on the android-ndk mailing list, with Android lead developers, and it came out to be reliable. These are not suppositions. There have been numerous discussions. And here's the conclusion about accessing another app's libraries, by Dianne Hackborn ("a Software Engineer who sits very near the exact center of everything Android"), answering my questions: http://groups.google.com/group/android-ndk/msg/05aae4aafb266cf1 Now, on Andraudio, I have indicated that there's a security issue. Indeed, Dianne insists a lot on the fact that altough loading and running a third party .so is absolutely feasible, it happens at 100% under the responsibility of the app which executes the code. What this means is that, if an app loads a malicious plugin, then it could be reported as a malicious app, and be banned from the Market, etc... Yes, you misunderstand the permission system and the Android security model. I'm not implying any kind of rooting and all that. I'm talking about plain non-rooted standard Android. On Android, the security model regarding applications is based on sandboxing. Such sandboxing in turn relies on the fact that each application gets assigned a unique user ID. And permissions (internet access, sdcard write access, etc...) are bound to the user ID. Reading data from another application directory or APK is not affected by this permission at all. Actually, preventing such read access is considered "futile": http://groups.google.com/group/android-ndk/msg/15a412a317a034bf But this doesn't allow a given application to perform what another application has the permissions to do. App A can read/execute the data and code provided by app B, but it doesn't grant the permissions of app B to A, because of user ID sandboxing. For this very purpose, an application can actually define custom permissions, that third party apps have to request explicitly (and the user agree), so that another app can for example call a restricted remote API through (Binder) IPC. -- Olivier

On 06/29/2011 07:59 PM, Nick Copeland wrote: No, when building with Android NDK using the armeabi-v7a ABI, hard floats are used. This works on ARMv7, which means a lot of devices, and certainly the majority. Soft floats are insanely slow on Android in my experience. You got an FPU on most devices, you can compile for hard floats, activate ARM NEON if you wish too, and even check for cpu features at runtime. I don't see why you want to use the GPU for optimization. -- Olivier

On 06/29/2011 10:33 PM, Nick Copeland wrote: I don't know what syscall you are talking about. When you build with the android NDK, you can choose to compile for armeabi, for armeabi-v7a or for both. If you only build for the later, then your app is not visible to non ARMv7 devices on the market. I can't remember what happens if you try to install the APK manually on an ARMv5 device, but I think this fails or doesn't run. If the app's built for both ABIs, then the package installer installs the proper set of libraries provided by your app, either armeabi or armeabi-v7a depending on the hardware. Also, there's a small library provided by the NDK, called cpu-features, which allows you to detect CPU features at run time. I used that and rely on it to activate certain features. It works great. AFAIK, on Android, there's no such thing as executing FPU instructions on devices without an FPU, unless you are doing something very weird. This 1000 factor and the syscalls you mention is something I never heard about, which is maybe true in general about ARM, but which doesn't happen in practice on Android, if you use the standard build tools and OS. That said, a factor of 10 or 20 is enough for me to call it insane, yes :p Okay, right, that's interesting. But, well, you got plenty of FPUs out there, and you just need a single line in a makefile to use them. That was my point. -- Olivier

On 06/30/11 09:26, Jens M Andreasen wrote: It's Dalvik: http://en.wikipedia.org/wiki/Dalvik_(software) HTH

(USB) MIDI appears to be missing - or am I looking in the wrong places? I would have wanted one of those underpowered tablets that people are dumping left and right as a midi-sysex controller /j [Ctrl-L == Reply-to-List] On Thu, 2011-06-30 at 11:53 +0200, Olivier Guilyardi wrote:

Agreed - that page is about something entirely different On Thu, 2011-06-30 at 13:49 +0200, Olivier Guilyardi wrote:

Yes, but that page is about communication upstream to the host ... I think the idea here is that most Androids are phones and by nature not intended to work as your main device. But there are no midi devices in existence that works like a host, unless you consider your main computer a midi device (well, it could be - kind of - but impractical in this context) There are some other development going on though with "normal" USB classes, notably USB_CLASS_SOUND, so in a not so distant future this may be extended to javax.sound.midi also /j On Thu, 2011-06-30 at 19:49 +0200, Olivier Guilyardi wrote: