Re: [LAD] LV2 realtime safe memory pool extension

David Olofson <david@email-addr-hidden> writes:

> On Thursday 08 November 2007, Stefano D'Angelo wrote:
> [...]
>> I'm not a plugin developer and I have nothing to do with LV2, but
>> anyway I think it can be a useful thing and that it is good to have
>> one "standard protocol" for this in LV2, instead of letting plugins
>> rely on external libraries or, even worse, include their own rt-safe
>> memory allocator.
>
> Yes, that's exactly my point, but I think it needs to deal with
> arbitrary size chunks to actually be able to serve that purpose in
> real applications.
>
> To avoid plugins effectively allocating private pools (just as if
> they'd implemented it internally), a host would have to use a proper
> real time memory manager, and then, whey not just make that available
> directly to plugins?

It is quite possible that some other plugin may need arbitrary size
chunks. It is just that lv2zynadd does not need such (to my current
knowledge about Paul's synth). And the point is whether arbitrary sized
chunk memory functionality should be exposed as separate extension or in
same one with pool based.

> BTW, are the blocking allocation calls intended for background
> threads...?

So far they are used during plugin instantiation. Background threads
should probably be exposed as another extension if some plugin needs
them.

> Wouldn't it be more useful with some interface that allows plugins to
> request memory in a non-blocking manner, and if instant allocation
> fails, have the host notify the plugin when the memory is available?
> Basically, a malloc() call that means "If I can't have this memory
> right away, please expand the pool so I can have it later!"

> The alternative would be to use the blocking version only
> in "background" threads, but unless you need background threads
> anyway, to do actual work, this is just moving complexity into
> plugins for no gain. If a plugin wants some memory to play around
> with "in the near future", it shouldn't have to implement it's own
> asynchronous memory management just to avoid stalling the host's
> audio thread.

With pool/lv2dynparam approach, you say min preallocated chunks greater
than zero. And make your algorithms retry call operation next time
(allocate new voice).

IMO, point of plugins is to have complexity moved from lots of plugins
to fewer hosts. And preferably packaged as libraries to ease code reuse
(as it is with lv2dynparam libs).

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev