Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: David Olofson (david_AT_gardena.net)
Date: ti maalis 07 2000 - 20:13:21 EST
On Tue, 07 Mar 2000, Paul Barton-Davis wrote:
> >> >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.
I'm not sure this is safe to assume... It might be possible to solve
for Linux (although it looks like a cludge to me to override
"system" library calls for parts of on application), but I'm not sure
if it's at all possible in other environments. AFAIK, a Windows DLL
would dynamically link to the system DLL where the memory management
stuff is. (Ok, Windows... But some people actually still care about
it. ;-)
> >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.
Well, brk is the little problem that an RT host has to be able to
avoid... I just don't like the idea of forcing such implementations
to rely on tricks with the dynamic library loader. Not all platforms
are as flexible as UN*X.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST