[LAD] wiki page: dead projects
Hello, I created this wiki page http://wiki.linuxaudio.org/apps/all/dead_projects which stems from a thread I had started about a year ago here on LAD, asking for people to tell what software they found very valuable but no longer maintained. I have no prior experience with the wiki so I probably have made some mistakes, first of all for example I'm not sure if the page is placed in the right place. Would someone with more experience kindly point out or even better correct these mistakes? Also, maybe a distinction should be made: for example, while jack-rack AFAIK doesn't have a dev periodically maintaining it, I think no one would call it dead, since it is quite usable and used; I'm pretty sure that if in the future it wouldn't compile anymore due for example to some gtk libraries not backwards compatible, someone would pretty fast come up with a patch. So, does it belong to the list? Or should we just change the name to abandoned projects, and thus even examples like jack-rack would fit in? As of now there are two problems with the content of the page: 1) Tau physical modelling is a software that was mentioned in the said LAD thread, but I couldn't find it anywhere online. links anyone? 2) Softwerk by Paul Davis was mentioned, but then Paul chimed in and said he had just committed to svn, however I couldn't find the svn address... So, Paul, could you kindly provide us the svn address, to add maybe here http://apps.linuxaudio.org/apps/all/softwerk or if you're no longer working on it, could we add it to the list? Ideally this page would be a place where developers in search for a nice project would go, so I would find it good to link to it in some places, but I'm not sure where... probably here http://wiki.linuxaudio.org/apps/categories/development would be a good idea, but I wasn't able to edit the page. Then maybe even some place more upfront like here?: http://www.linuxaudio.org/resources cheers renato ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] wiki page: dead projects
On 06/29/2011 10:25 AM, Renato wrote:
Hello, I created this wiki page
http://wiki.linuxaudio.org/apps/all/dead_projects
which stems from a thread I had started about a year ago here on LAD, asking
for people to tell what software they found very valuable
but no longer maintained.
I have no prior experience with the wiki so I probably have made some
mistakes, first of all for example I'm not sure if the page is placed
in the right place. Would someone with more experience kindly point out
or even better correct these mistakes?
I've started doing that. But I'm short on time these days. I May not get
around to attend to this before the week after next.
The generic way to do this it to simply add the tag unmaintained to
each project, then they'll automatically end up at
http://wiki.linuxaudio.org/apps/categories/unmaintained
Just add {{OTHER TAGS unmaintained}} to the page of the app e.g.
http://wiki.linuxaudio.org/apps/all/rezound
Also, maybe a distinction should be made: for example, while jack-rack
AFAIK doesn't have a dev periodically maintaining it, I think no one
would call it dead, since it is quite usable and used;
That's why we call it unmaintained :)
I'm pretty
sure that if in the future it wouldn't compile anymore due for example
to some gtk libraries not backwards compatible, someone would pretty
fast come up with a patch. So, does it belong to the list? Or should we
just change the name to abandoned projects, and thus even examples
like jack-rack would fit in?
For non-generic info, create a wiki page. f.i.
http://wiki.linuxaudio.org/wiki/projects_that_need_loving
link to the app in question (e.g. [[:apps:all:rezound]]) - and add
detailed info there.
The :apps:all:* name-space at http://wiki.linuxaudio.org/apps/all/*
should only contain applications and no custom-pages.
As of now there are two problems with the content of the page:
1) Tau physical modelling is a software that was mentioned in the said
LAD thread, but I couldn't find it anywhere online. links anyone?
2) Softwerk by Paul Davis was mentioned, but then Paul chimed in and
said he had just committed to svn, however I couldn't find the svn
address... So, Paul, could you kindly provide us the svn address, to
add maybe here
http://apps.linuxaudio.org/apps/all/softwerk
or if you're no longer working on it, could we add it to the list?
Ideally this page would be a place where developers in search for a
nice project would go, so I would find it good to link to it in some
places, but I'm not sure where... probably here
http://wiki.linuxaudio.org/apps/categories/development
The development tag is intended for libraries - handy for developers.
I'm in touch with Emanuel Rumpf off-list to update the wiki, re-style it
and clean out the tag mess.. it's on the top of my ToDo list for
July/August.
would be a good idea, but I wasn't able to edit the page. Then maybe
even some place more upfront like here?:
http://www.linuxaudio.org/resources
cheers
renato
Thanks for your contribution,
Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Android audio plugins
Hi guys! I just started a thread on andraudio about Android audio plugins and advanced app interaction, including LV2 and others: http://music.columbia.edu/pipermail/andraudio/2011-June/000238.html Feel free to join in. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
Hi Olivier, Good stuff! On Wed, 29 Jun 2011, Olivier Guilyardi wrote: I just started a thread on andraudio about Android audio plugins and advanced app interaction, including LV2 and others: http://music.columbia.edu/pipermail/andraudio/2011-June/000238.html Feel free to join in. Here's a potential problem (but I could be misguided... so you guys tell me)... - Mobile processors generally do NOT have good floating point power. Sometimes by a factor of 1000 flops. - LADSPA and LV2 are built to process 32-bit floating point PCM data, and have no provision for processing 16-bit integer PCM data. So, trying to use LADSPA or LV2 in their current state will probably cause bottlenecks (either from doing FP math or from doing format convervsions to do integer math). Is this a Real Problem? -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
Hello Gabriel, On 06/29/2011 06:19 PM, Gabriel M. Beddingfield wrote: Good stuff! Thanks :) By the way, if you don't mind, I think it would be nice to centralize the discussions on the andraudio thread. On Wed, 29 Jun 2011, Olivier Guilyardi wrote: I just started a thread on andraudio about Android audio plugins and advanced app interaction, including LV2 and others: http://music.columbia.edu/pipermail/andraudio/2011-June/000238.html Feel free to join in. Here's a potential problem (but I could be misguided... so you guys tell me)... - Mobile processors generally do NOT have good floating point power. Sometimes by a factor of 1000 flops. I can't give you any precise specification, it all depends on the device, but for instance I can encode to OGG in realtime without any problem using hard floats on ARMv7, which means a real lot of devices nowadays. Also, dual core devices such as the Motorola Atrix are getting popular. That may help. - LADSPA and LV2 are built to process 32-bit floating point PCM data, and have no provision for processing 16-bit integer PCM data. So, trying to use LADSPA or LV2 in their current state will probably cause bottlenecks (either from doing FP math or from doing format convervsions to do integer math). Is this a Real Problem? It depends. First, usage. Offline processing (my case, I develop a sample editor) is okay, it just takes a little more time. You can use floats, it's not an issue. But if you want to do realtime effects, then you may need to limit which or how many plugins you use. Second, optimization. When working on a mobile platform, you currently need to optimize plenty of things. But, for example, in my own experience the worse bottleneck is disk (SDCard) I/O, not CPU/FPU. SDCard can be slow and lag terribly on certain devices. Regarding CPU usage, of course, I'm very cautious about which features I include. Maybe that some plugins could easily be modified to use fixed-point optionally (LV2 extension?). As an example, KissFFT can be compiled for floats or fixed point, as you like. That said, honestly, it needs some plugin-specific testing, but I believe that floats are just fine in many cases. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On Wed, 29 Jun 2011, Olivier Guilyardi wrote: By the way, if you don't mind, I think it would be nice to centralize the discussions on the andraudio thread. Agreed, but I think this particular aspect needs a little LAD input (*cough*torben*cough*). :-) Is this a Real Problem? It depends. First, usage. Offline processing (my case, I develop a sample editor) is okay, it just takes a little more time. You can use floats, it's not an issue. But if you want to do realtime effects, then you may need to limit which or how many plugins you use. 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. Maybe that some plugins could easily be modified to use fixed-point optionally (LV2 extension?). As an example, KissFFT can be compiled for floats or fixed And this is what I'm wondering... could/should this be done with an LV2 extension? -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
And this is what I'm wondering... could/should this be done with an LV2 extension? I'm not qualified to answer that. Although, something like the HTTP Accepts header and content negotiation comes to mind. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
- Mobile processors generally do NOT have good floating point power. Sometimes by a factor of 1000 flops. 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. - LADSPA and LV2 are built to process 32-bit floating point PCM data, and have no provision for processing 16-bit integer PCM data. 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. So, trying to use LADSPA or LV2 in their current state will probably cause bottlenecks (either from doing FP math or from doing format convervsions to do integer math). Is this a Real Problem? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On Wed, 29 Jun 2011, Nick Copeland wrote: - LADSPA and LV2 are built to process 32-bit floating point PCM data, and have no provision for processing 16-bit integer PCM data. 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). Most LV2 and LADSPA plugins do the DSP work in floating point... so... yes. :-) But, here's what I'm getting at. Suppose you optimize your plugin chain for fixed-point (integer) math but use the current LV2 protocol. A prosaic approach is: 1. Synth plugin. generates audio. Converts to float. sends to next plugin 2. FIR filter. Converts float to int. Processes data. Converts int to float. Sends to next plugin. 3. Convolution Reverb Converts float to int. Processes data. Converts int to float. Sends to next plugin. All those needless conversions don't settle right with me. 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? Why would we? Because they're mature technologies. Why reinvent the wheel? 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? Maybe today, with tablets. But not their phones. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
Most LV2 and LADSPA plugins do the DSP work in floating point... so... yes. :-) [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. All those needless conversions don't settle right with me. 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. 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? Why would we? Because they're mature technologies. Why reinvent the wheel? 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. 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? Maybe today, with tablets. But not their phones. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On Wed, 29 Jun 2011, Nick Copeland wrote: Maybe today, with tablets. But not their phones. 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 Who's talking about getting apps to interoperate? Not me. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
Who's talking about getting apps to interoperate? Not me. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On Wed, 29 Jun 2011, Nick Copeland wrote: Who's talking about getting apps to interoperate? Not me. 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. Ah, thanks. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On 06/29/2011 09:07 PM, Nick Copeland wrote: Who's talking about getting apps to interoperate? Not me. No, but you are talking about getting developers to interoperate. The 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On 06/29/2011 07:59 PM, Nick Copeland wrote: - Mobile processors generally do NOT have good floating point power. Sometimes by a factor of 1000 flops. 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. 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. 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On Wed, 29 Jun 2011, Nick Copeland wrote: Perhaps I have missed the point, Android security prevents you accessing resources that you have not been given a priori permission to use to ensure the system cannot be compromised by malicious code. If you want to root your 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
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. But then every other system gets the rough 1000 factor performance hit that started this thread since all other CPU have to do a system call to execute the float operation. Designing for a single handset family is not that scalable. 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. Soft floats are insanely slow on Android in my experience. A factor of 10 or 20 over hard floats? Sound about right? The factor 1000 is for code that uses FPU instructions on systems without the FPU support. That I would call insanely slow but you can choose which way you go here. 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. Man, the recent chipsets have 6 of these pipelines - designed for graphics processing but sitting there waiting for audio DSP. Regards, nick. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Petri-Foo preview release: 0.0.2
Hello hello, The second official source code release Petri-Foo is now available. IMPORTANT: I have designated this release as a 'preview' release to indicate this is still a work in progress so that users may be aware things may change and their files may not be usable without alteration in future versions. HOWEVER: I feel Petri-Foo has moved along quite nicely since 0.0.1 in April and would like to share that work with a few more of you than are subscribed to the Petri-Foo developers list. WHAT'S NEW and good (since 0.0.1): * Default Patch A default patch using a looped generated triangle wave sample, with an ADSR, LFO, and MIDI CC setup with sensible/default values so a new user can immediately hear audio. * Selectable MIDI controllers MIDI controllers are now selectable amongst all the other modulation sources. This has two benefits, the first is being given the choice (of course), and the second is that you can now control how much effect the controller has. * Patchlist context menu You can now right-click on the patch list to get a context menu to allow you to perform add, remove, rename, and duplicate operations on patches. * Keyboard tracking Keyboard tracking has been added to all the parameters, and additionally, to the envelopes where it modifies envelope duration. * LFO Amplitude modulation The LFOs now have amplitude modulation so that. For example, the default patch uses this in combination with the MIDI Mod Wheel controller to control pitch modulation. * RAW sample format loading Allows one to load files never intended to be heard :-) * Removal of LASH support * Removal of ALSA *audio* output (note: ALSA MIDI still supported) * Miscellaneous bug fixes and GUI clean ups. Home pages... http://petri-foo.sourceforge.net http://github.com/jwm-art-net/Petri-Foo Download... http://sourceforge.net/projects/petri-foo/files/Source/petri-foo-0.0.2.tar.gz/download git clone git://github.com/jwm-art-net/Petri-Foo.git Bug reports... https://sourceforge.net/tracker/?group_id=404816 jwm.art@gmail.com Mailing list... https://lists.sourceforge.net/lists/listinfo/petri-foo-devel please note, if you're not a member your messages are automatically rejected :-p cheers, regards, James. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On 06/29/2011 10:31 PM, Gabriel M. Beddingfield wrote: On Wed, 29 Jun 2011, Nick Copeland wrote: Perhaps I have missed the point, Android security prevents you accessing resources that you have not been given a priori permission to use to ensure the system cannot be compromised by malicious code. If you want to root your The permissions system you are talking about is something else. Yes, if this can't be overcome[1] then it defeats the purpose of a plugin system. [1] That is, overcome without jail-breaking your device. Loading shared libraries provided by another app is not an issue at all. No need to root (jail-break is an iPhone expression ;). When an app installs, the .so files that it bundles are automatically extracted to the application data directory. And this directory can be accessed by other apps. You can directly System.load() it from Java or dlopen() it from C. It's as simple as that, and according to the discussion I had with Android lead developers, there's no reason that this changes. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On Wed, 2011-06-29 at 11:59 -0500, Gabriel M. Beddingfield wrote: [...] And this is what I'm wondering... could/should this be done with an LV2 extension? Sure; it is straightforward to define new LV2 port types. (Warning: LV2 design tangent follows) However, the more I think about it the more I resent the hard distinction between port types. Us still being stuck with the tinkertoy control ports inherited from LADSPA are the most obvious effect of this. If people want to start playing with alternative sample formats, defining a different port type for each would pose a problem: you need a separate plugin for every sample type. Perhaps this would be okay, since you'd only want one on a given platform anyway, but it seems a bit weak. A more dynamic way to allow a plugin to work with whatever dynamically configured sample format would seem to be better... which is yet another argument for what I increasingly think is the best way to go with LV2 plugin I/O in general: To me (with good ol' 20:20 hindsight), it seems that a single port type that receives messages would be much better than the current situation[1]. Messages would have a standard binary compatible header which distinguishes the various types (much like the current provisional atom extension[2]). Separate units which communicate via generic well defined messages is well-known as a solid computational model with many advantages; it seems to map best to plugins (since many plugins are stateful so purely functional ideas are out, anyway). The plugin can simply list in the data that this port supports such and such message types, and - if necessary - the host could configure the plugin to expect whatever types of messages it will be delivered. In this case, float audio, double audio, int16_t audio, or whatever. Anyway, the above is a more general how discussion mostly of interest to LV2 folks. As for the pragmatic issue of sample formats at hand, the answer is, as always: sure, we can do that. It would break compatibility with existing hosts, though. [1] Actually, I think there are fundamentally /two/ primitive types of ports based on the semantics of how they consume their value: value ports and message ports, but that's a tangential discussion. Suffice to say here that audio ports are messages because they /consume/ their input, so nevermind values. [2] http://lv2plug.in/ns/ext/atom/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android audio plugins
On 06/29/2011 10:33 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. But then every other system gets the rough 1000 factor performance hit that started this thread since all other CPU have to do a system call to execute the float operation. Designing for a single handset family is not that scalable. 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. 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. Soft floats are insanely slow on Android in my experience. A factor of 10 or 20 over hard floats? Sound about right? The factor 1000 is for code that uses FPU instructions on systems without the FPU support. That I would call insanely slow but you can choose which way you go here. 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 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. Man, the recent chipsets have 6 of these pipelines - designed for graphics processing but sitting there waiting for audio DSP. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
