[LAD] LV2 realtime safe memory pool extension

David Olofson david at olofson.net
Thu Nov 8 12:07:41 UTC 2007


On Thursday 08 November 2007, Nedko Arnaudov wrote:
[...]
> The point is that some plugins need *realtime safe* memory
> allocation.

Well, yes; that part is quite obvious.

What I meant was, if all the host provides is a pool of uniformly 
sized chunks that are allocated when the plugin is initialized, there 
doesn't seem to be much point in implementing it on the host side. 
The naïve host side implementatio would add exactly nothing, compared 
to plugins just allocating their own pools during initialization.

A proper real time manager, with arbitrary chunk sizes, would be more 
motivated, as it adds functionality that plugins can't implement 
internally; namely a shared memory pool.


> I  
> need this functionality for lv2zynadd plugin (like arbitrary voices
> count allocation)

The "standard" solution is to pre-allocate and pre-initialize voice 
structures for a fixed maximum polyphony.

Obviously, this becomes troublesome with modular synths and the like, 
where the "voice structure" doesn't have a fixed size.

One solution is to allocate the voice pool as a response to "program 
change" events. Of course, this makes the "programe change" operation 
non real time safe, but it usually is anyway, due to samples being 
loaded from disk and stuff. Many systems, both hardware and software, 
are based entirely on the idea that patch loading is part of 
setup/initialization, as that is often the only practical solution. 
It's really only entirely ROM based synths (or "small fixed sample 
set", in the case of software), virtual analog synths and the like 
that *can* implement real time safe "program change" at all.


> and for lv2dynparam plugin library internal 
> operation too.

It needs to "regroup" internally as a response to certain parameter 
changes?


> There were rumors in #lad that such functionality may be useful
> without lv2dynparam extension.

Well, yes; real time safe dynamic memory management can make life a 
lot easier for some types of plugins, and/or reduce memory 
requirements by having a shared pool. However, I think it needs to be 
more generic than just a pool of fixed size chunks for the "shared 
pool" part to be viable.


[...]
> That reminds me that LV2 may need a way to specify optional features
> that interdepend. I.e. features (extensions) A and B are both
> optional but if A is provided B is required. Of course plugin can
> check this explicitly on instantiate and refuse to use feature, but
> I'm not sure how vital is such approach.

Haven't really thought about this... Isn't it just a matter of plugins 
and hosts listing *all* extensions? I mean, if you provide or ask for 
this feature A, but not feature B, you have a bug. An automatic 
validation tool would trap this right away - but of course, 
someone/something has to tell the *tool* about these extension 
interdependencies...


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'



More information about the Linux-audio-dev mailing list