26 Feb
2011
26 Feb
'11
6:45 p.m.
2011/2/26 Olivier Guilyardi <list(a)samalyse.com>om>:
On 02/26/2011 05:47 PM, Stefano D'Angelo wrote:
Ah, didn't know. :-) Never actually used the NDK, only the SDK.
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. 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.
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
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
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.
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