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

[Stefan Kersten]

On 28.02.12 00:36, David Robillard wrote:
> On Mon, 2012-02-27 at 11:21 +0100, Stefan Kersten wrote:
>> On 27.02.12 01:01, David Robillard wrote:
>> [...]
>>>> the idea is to keep instance creation overhead as low as possible; "placement"
>>>> instantiation saves one call to the allocator and is possible for many plugins
>>>> (in my case most of them generated by faust). an allocator feature still makes
>>>> sense though, for plugins that don't know their memory requirements at compile time.
>>>
>>> Fair enough (though it's just one function call). 
>>
>> it might be a relatively costly function call and a compact memory layout should
>> also improve locality of reference.
> 
> Well, for former is the host's choice either way, really, but fair
> enough.  No argument against the latter, flat blobs of data are
> superior.  The problem is that this interface *only* works for plugins
> where the entire instance is one flat blob of data.
> 
> Maybe that's not a problem since it's a good thing if you can achieve
> it.  I'm not sure.  Just thinking out loud.

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);
};

>>> What do you need dynamic alignment for?
>>
>> it's probably not really needed (and not really dynamic), but since the instance
>> is constructed within a larger block of memory along with some state and
>> audio/control buffers, the `instance_alignment' function is supposed to return
>> the required alignment of the structure in order to place it correctly into memory.
> 
> Difficult to realize portably.  Since it's not really dynamic and I'd
> bet that you really just need a specific alignment (e.g. 64-bits for
> SSE) I'd probably just make this a static rule.  Things being aligned to
> 64-bits is already established in LV2 land (events).
>
> Some platforms, e.g. OSX, guarantee this for any malloc, so you don't
> need to implement special alighment.

my runtime instances look something like this right now (all in one chunk of
memory):

[some state] <- aligned to 16 byte boundary
[bus mapping state]
[LV2 instance] <- aligned to `instance_alignment' boundary
[control port buffers]
[audio port buffers] <- each aligned to 16 byte boundary

you're right that the instance alignment should be made a static rule. in any
case the instance alignment can only be accommodated for when it is smaller than
or equal to the memory alignment of the whole block (without knowing the
address, if i get this right), so it's probably better to guarantee an alignment
equal to the maximum requirement on a given platform (usually 16 bytes for the
SIMD vector types).

>>>> yes. i've been rolling my own plugin API when i realized that LV2 does almost
>>>> everything i need and is extensible enough to make it do virtually anything.
>>>> good work!
>>>
>>> Best to get along with others if at all possible :)
>>
>> yeah well, at the moment i am abusing LV2 as an internal plugin format for a
>> specific host, but with the intention to be able to load "standard" LV2 plugins
>> at some point ;)
> 
> Sure.  Ideally you should seek to eventually have it work the other way
> around too, i.e. standardize the extensions so the plugins work in other
> hosts as well.  If they are meaningful at all in other hosts, anyway.

sure, i'll publish the extensions once they stabilize a bit and once i've
wrapped my head around RDF (this is all quite new for me).

> I might have some personal self-interest in doing so (Ingen); what kind
> of plugins are you making here?

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.

<sk>

[1] http://faust.grame.fr/
[2] http://supercolliderbook.net/rossbencinach26.pdf