linuxaudio.org

On 02/26/2011 05:47 PM, Stefano D'Angelo wrote:
> So, the latest SLV2 has dropped librdf in favor of a minimal

quoted text
> 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

quoted text
> 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.
The only way to know what size it will really take is to compile with the

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.
I haven't played so much with flags such as -Os because there's like a very very

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.
I don't want to wake up old trolls, but last fall, when I had a sound engineer

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

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.
--

  Olivier
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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