Re: [linux-audio-dev] Simple Plugin API: In/Out Ports

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: David Olofson (david_AT_gardena.net)
Date: ti maalis 07 2000 - 22:27:23 EST


On Wed, 08 Mar 2000, Paul Barton-Davis wrote:
[...]
> However, even if I did, that just means you need a #define in either
> the host or/and the plugin headers. No big deal.

Ok, as long as you don't need the source for all plugins just to
recompile them so they'll work with a real time engine. I seriously
doubt that we'll see any proprietary applications or plugins if that's
the case.

> >> 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.
>
> Sure, but this has nothing to do with malloc. brk(2) is just the
> underlying way that malloc gets more virtual memory to work with. on a
> DOS system, some other method is used. in the type of RT host you're
> describing, its important to basically *never* call the underlying
> method while running plugins. None of that invalidates the very
> efficient ways that malloc allocates the memory is managing. As I
> said, malloc does fall down in some areas, but these are not likely to
> be ones that plugins will use much, if at all; the default
> implementations are also not very SMP/thread friendly, which is why
> libhoard is important - its a malloc implementation that is extremely
> SMP/thread friendly, and will run on more or less any platform with an
> ANSI-ish C compiler.
>
> I wasn't advocating that you just use the malloc in libc; what I was
> advocating was the reuse of 99% of all the code from an existing
> malloc implementation rather than coming up with some new attempt to
> "make malloc better".

I haven't suggested that. My idea was to somehow allow hosts to
control what suballocator plugins are actually using when they use the
memory management calls - not defining a completely new API for
memory allocation. That's only useful for situations where pools of
equally sized objects and the like wold fit in, ie the event system,
which is a completely different matter.

> Since this has been done at least a dozen times
> by some very notable CS folk over the years, its pretty unlikely (not
> impossible, just unlikely) that such an attempt will be fruitful.

We'll leave that to anyone that would like to hack the world's
fastest engine... :-) The implementation is irrelevant here.

> The 1% that you alter is the part that calls brk(2) ... of course.

Yes. I just want to make sure that you don't end up with the cludge
of the century just because you want to use both the normal mm code
*and* the RT safe, non-brk version in the same application, using the
latter for the RT thread(s) only.

OTOH, it might be a better idea to run the RT engine as a separate
application anyway... :-)

//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 -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST