[LV2] --SPAM--::Re: [Devel] lv2_descriptor() considered harmful

Stefan Kersten sk at k-hornz.de
Tue Feb 28 10:58:04 PST 2012

On 28.02.12 19:27, David Robillard wrote:
> On Tue, 2012-02-28 at 11:10 +0100, Stefan Kersten wrote:
> [...]
>> i intend to create most plugins with faust [1], which generates c++ code that
>> doesn't do dynamic memory allocation. for the cases where i do need dynamic
>> memory, i thought about a separate extension providing a realtime allocator
>> feature, something like:
>> struct LV2_RT_Allocator {
>> 	void* (*alloc)(LV2_RT_Allocator* self, size_t size);
>> 	void* (*alloc_aligned)(LV2_RT_Allocator* self, size_t alignment, size_t size);
>> 	void (*free)(LV2_RT_Allocator* self, void* ptr);
>> };
> There is this, though it's quite a mess that needs to be cleaned up:
> http://lv2plug.in/trac/wiki/Rtmempool
> I am not sure there is a point though.  Is there a significant advantage
> to forcing the host to supply this functions vs. just including a pool
> in your plugin if you need it?

if plugin instantiation should be realtime safe, the host needs to have a
realtime memory manager anyway, so there's no need to include a pool in every
plugin. then there's also only one place to decide how much memory to allocate
for the realtime thread.

>> i am working on an audio engine for mobile and server-side realtime rendering.
>> currently planned are plugins for disk-based sample playback, spatialization,
>> nothing fancy really. the architecture is similar to supercollider's scsynth
>> [2], that's why plugins (`SynthDefs' in SC parlance) need to be
>> realtime-instantiatable by default in order to be able to use them e.g. as
>> voices in a synthesizer. for other LV2 plugins the plan is to instantiate them
>> in a non-realtime thread and send the new instance to the audio thread.
> If you're pre-allocating the memory for them anyway, is there really a
> difference from just pre-instantiating a bunch plugins beforehand?

the difference is that you would need to decide how many to instantiate for each
plugin; it's like the difference between a memory manager and a pre-allocated
free-list, efficiency vs. flexibility. in this case i'll trade efficiency and
keep flexibility ;)


More information about the Devel mailing list