linuxaudio.org

2011/2/26 Olivier Guilyardi :

quoted text
> On 02/26/2011 05:47 PM, Stefano D'Angelo wrote:

>

>> So, the latest SLV2 has dropped librdf in favor of a minimal

>> RDF/Turtle implementation already done by Dave himself. Such

>> implementation is basically made of two libraries: Serd (parser) and

>> Sord (triple store).

>

> I was unsure librdf. It's good to know that it's not needed anymore

>

>> Here is the size of the current svn SLV2 and its dependencies on my

>> machine (arch linux x86-64), all stripped, yet probably compiled with

>> -02, excluing glib: libslv2 is 61K, libsord is 29K, libserd is 44K,

>> libpcre is 236K (I didn't know it was a dependency, what is it for

>> Dave?). That means: slv2+sord+serd = 134K, adding pcre is 370K.

>>

>> Now, libnacore when stripped is 56K... if it could substitute both

>> pcre and glib, it would mean the whole stack = 190K + something else.

>>

>> Considering that Android platforms are probably 32 bit (right?) and

>> stuff could be compiled with -Os, I would say we would end up

>> somewhere in between 100 to 250K. Is that still too much?

>

> Yes, ARM, 32bit. But, with the Android NDK, "By default, ARM target binaries

> will be generated in 'thumb' mode, where each instruction are 16-bit wide.".

> This is intended to save space.

Ah, didn't know. :-) Never actually used the NDK, only the SDK.
> The only way to know what size it will really take is to compile with the

quoted text
> Android NDK. Also, linking statically when using a reasonable set of SLV2

> functions would give a more realistic figure. This should also avoid extra ELF

> stuff when creating an .so.

Ah sure, static linking would cut out some unneeded code too. Don't

really know how much actually.
> I haven't played so much with flags such as -Os because there's like a very very

quoted text
> careful mood about portability when compiling native libraries for Android. The

> NDK already sets various optimization flags. But this could be worked around.

>

> Something like 100k-200K could be fine in my case, at the condition that adding

> LV2 support provides a real benefit in terms of functionality.

This depends on what you are using it for and how. Being decentralized

& extensible, you could also use it to make coffee. :-)
> I don't want to wake up old trolls, but last fall, when I had a sound engineer

quoted text
> intern working on the topic, we ended up thinking that integrating LADSPA would

> really be straightforward. No such overhead, great portability, and plenty of

> plugins.

> So most logically, when time comes to add plugin support, I will start with

quoted text
> LADSPA. LV2 will maybe come afterwards. But this could change if there suddenly

> is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages arrive

> on the Android Market.

I respect your choice and understand the rationale. Also, all of this

changes won't happen by tomorrow (my guess is 2/3 months, based on

feeling more than facts), so if you "need effects soon", you should

probably go that route.
However, in the long run, I would avoid LADSPA for two reasons: 1.

lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts

without explicit support through the NASPRO bridges (which will be

able to work by default with SLV2 starting from the next SLV2 release,

otherwise you can grab the current svn SLV2 already).
So it turns out it depends on how long you want to wait, or rather if

you would consider giving some help, and what you want to do with LV2.
HTH,
Stefano

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev