Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma maalis 06 2000 - 22:54:01 EST
>> >It is, but you only have to mlock() the stuff that the engine thread
>> >will touch. (That includes the stack...)
>>
>> No big deal. You mlock everything you need once the thread is up and
>> running and the host is ready to accept plugins. Then you selectively
>> mlock new buffers, plugin code and data segments etc. etc.
>
>How do you keep track of what memory has been allocated from plugins
>and not from some(non-RT) part of the application?
you (run time) link the plugins so that their calls to the malloc()
replacement does the required housekeeping, but that other parts of
the application are using a different function. i'm pretty sure that
this can be done with the linux run time linker, and if not, its just
a matter of a #define in the host application.
>> >One could turn it around and say that the malloc()/free() interface
>> >isn't allowed to be used inside the process() (or run()) call of RT
>> >capable plugins. That means that any plugin that still wants some
>> >form of dynamic memory management has to grab a pool during init, and
>> >use it's own, custom memory management.
>>
>> Well, you could also say that dynamic memory management isn't allowed
>> inside of plugins.
>
>How about a sequencer plugin? How much memory should it allocate?
>What if you're using multiple plugins of that kind together?
I was being somewhat rhetorical :)
>> If a delay line is needed, it needs to be set up in
>> the instantiation routine. This can be wasteful, since it means you
>> have to allocate the maximum amount, rather than whats needed when its
>> needed, but I don't see you can avoid this inefficiency with a custom
>> pool system, or any other system for that matter: either we have all
>> the memory we might ever need, and its just a matter of chunking it up
>> into the pieces the plugins need, or we don't, and we have to call
>> brk(2) at some point to get more. I don't see any middle way here.
>
>It's quite impossible to hack a generic malloc()/free() style memory
>manager that can handle large, contigous blocks without directly
>fiddling with the virtual memory tables (that is, a kernel job). But
>not all plugins require that kind of dynamic allocation.
>
>Anyway, this is probably irrelevant to LADSPA, as it can't take
>plugins with that kind of complexity, so the really complicated part
>with largel, contigous blocks goes away. It has to be handled the may
>you describe anyway - just as I intend to do it in MuCoS.
Right, but the way I describe is what malloc(3) excels at. At least if
you get an SMP-friendly version like libhoard. malloc takes a lot of
crap, but its an incredibly highly evolved design that works very well
for many cases. its major breakdown is in cases involving large
numbers of sequential malloc/free calls involving small amounts of the
same sized memory (e.g. STL lists of char, arghhh.....). in the case
we're talking about, a generalized allocation routine for plugins to
use during their VST-would-call-it-process() function, then as long as
it doesn't call brk(2), its great.
>> If you making a real recording, why
>> would you be messing around doing the equivalent of setting up a new
>> F/X rack at the same time ?
>
>I wouldn't. I'd just like to be able to change things while playing
>back, without having to either pause the playback (and confuse all
>external synthesizers and the like), or accept that the engine will
>stall, lose sync and other unpleasant stuff.
OK, point taken.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST