I think if you can read an .so you can load it. Had thought you needed execute permissions but found an example of a lib in an app without. I need to explicitly try it from another app for a different purpose anyway.
niko20 wrote: > I'm still not seeing how you could pass audio data to the plugin with > low latency buffering. I'm not sure if an app can "load" an .so from > another app so to speak. > > -niko > > On Sep 9, 12:54 pm, Kiall Mac Innes <[email protected]> wrote: > > You should try the android developers list rather than a general discussion > > list for this kinda thing... > > > > > > > > > Hi everyone, > > > > > I have a sound recorder and editor app on the market, and I'm currently > > working > > > on audio effects, such as reverb, compression, etc.. > > > > > For this purpose I will very likely use LADSPA plugins, which are in their > > vast > > > majority GPL licensed. This is a bit controversial, but according to my > > > googling, it is quite ok to load GPL plugins into a closed source app. > > But, the > > > plugins really need to be plugins, that is distributed as separated > > packages. > > > > > That said, this isn't only about legal stuff. I am seeing great > > opportunities > > > for the Android ecosystem concerning such audio plugins. I think that the > > high > > > interoperability abilities between apps (through intent filters, content > > > providers, etc..) is a great strength of the platform. > > > > > Therefore, if us developers were able to agree on some particular audio > > plugin > > > paradigm and discovery system, the Android audio world could become very > > > attractive to both users and developers. > > > > > In my current idea, a package (= an app on the market) may contain several > > > plugins, and there might be several packages from various vendors. Here, > > > discovery of the plugins by a given host should be quite easy to achieve > > by > > > using queryIntentServices() where each plugin package would expose a > > service > > > with a pre-defined intent filter. A content provider could also be used > > for > > > retrieving information about the bundled plugin. > > > > > Now, in regard to loading and communicating with a plugin, there are many > > > possibilities, some very complex. Right now, I am thinking about a very > > simple > > > first mechanism, where a host can retrieve LADSPA shared objects from a > > plugin > > > package through a content provider exposed by the said package. This will > > allow > > > for high performance by loading the .so in my native audio engine. > > > > > This is a very simple mechanism, though with some work, I believe that it > > should > > > be possible to distribute and load plugins which come with a UI, just as > > desktop > > > users do with VST instruments. > > > > > That said, what do you think about the general idea? Would some of you be > > > interested by such an audio plugin system? > > > > > -- > > > Olivier > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > > "Android Discuss" group.> To post to this group, send email to > > [email protected]. > > > To unsubscribe from this group, send email to > > > > [email protected]<android-discuss%2Bunsubscribe@ > > googlegroups.com> > > .> For more options, visit this group at > > > > http://groups.google.com/group/android-discuss?hl=en. > > > > > > > > -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
