[LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

David Robillard d at drobilla.net
Sat Feb 26 17:42:55 UTC 2011


On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote:
> 2011/2/25 David Robillard <d at drobilla.net>:
> > On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
> >> On 02/25/2011 08:57 PM, David Robillard wrote:
> >>
> >> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
> >> >> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
> >> >> changing IIUC :)
> >> >
> >> > You never asked. I would have changed it... but I am not psychic ;)
> >>
> >> It's not always easy to discuss about religious matters, such as licenses ;)
> >>
> >> That said there is another big problem. This glib dependency, it's way too heavy
> >> for mobile deployment.
> >
> > Glib was the most effective route of getting the job done - rewriting
> > the few bits that are required is not an effective use of my time right
> > now (it's not exposed in the API, so it's not a compatibility issue, and
> > there's a ton of more pressing LV2 things that need doing).
> >
> > I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
> > unoffensive a dependency as they come. On mobile, I guess that meg or so
> > actually makes a difference.
> >
> > Replacing glib will not be very difficult, very little of it is used:
> > just a balanced BST, dynamic array, and ideally a hash table or trie
> > other appropriate structure for string interning (the BST would do for
> > this part, with a bit of a performance cost). Good old-fashioned data
> > structure implementation is my favourite thing to do, but unfortunately
> > there is no shortage of more pragmatic things that need doing ;)
> >
> > Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
> > just tearing the required bits out of glib itself. Sqlite has an
> > in-memory hash table IIRC. Code abounds.
> >
> > Present a viable alternative, and I'll switch sord/slv2 to it, but I
> > have no good reason to invest time in reinventing glib right now.
> 
> Given the discussions we had already, NASPRO core could be a viable alternative.
> 
> Pros:
> - no dependencies apart from libc and libm
> - size (181K without stripping on Arch Linux x86-64, -O2)
> - high portability, little and confined platform-specific code,
> compiler-specific (symbol visibility, etc.) code confined to a small
> header
> - gracefully handles platform-specific conventions (i.e., ':' vs ';'
> in path variables, zero-length prefixes in path variables under *nix,
> directory separators, etc.)
> - total amount of code is circa 7.5k lines, including comments and
> public headers
> - UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
> counting is supported
> - thread safety (e.g., data types are synchronized at a very granular
> level, but allow you to have more coarse synchronization if you want)
> - extremely low memory footprint
> - locale-independent asprintf() and vasprintf(), C99 level (except
> "%lc" and "%ls" conversions, possibly they are not even needed if
> using UTF-8)
> - semi-serious, integrated and as-lightweight-as-it-can-be
> error/message reporting mechanism
> - precise and well defined error checking and error codes
> - includes directory traversal, dynamic loading
> - well documented
> 
> Cons:
> - not yet released
> - no real test suite and not extensively tested
> - currently implemented data types: doubly linked lists and AVL trees only
> - not yet ported to non POSIX platforms (i.e., Windows)
> - API/ABI are "stable enough", but can't guarantee for total stability
> in the next future (i.e., no big changes will happen, yet something
> might change)
> - no locale-independent sscanf() or similar
> - no UTF16-BE support/conversion
> - till now, a one man effort
> 
> That is, it is certainly possible to make it become viable to replace
> SLV2, but this is not high priority for me at the moment. Once the new
> NASPRO release is out I can consider whether to do the work, since I
> want to port SLV2 to Windows right after.
> 
> The decision, however, depends on whether Dave would like that or not.

Sure. Sounds good, probably a good choice, and it would be nice if your
work - originally intended to escape slv2 - could be used by it to make
a better general solution instead :)

Like you, I think releasing the current state of things is a higher
priority though. Plenty enough improvement and new libraries lately as
it is, time to kick it out the door and get it on users machines. We can
look into this.. y'know.. later.

-dr





More information about the Linux-audio-dev mailing list