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: to maalis 02 2000 - 17:39:04 EST


On Thu, 02 Mar 2000, Benno Senoner wrote:
> On Wed, 01 Mar 2000, David Olofson wrote:
> >
> > This is what VST does. It also allows plugins to define two versions
> > of the plugin callback; one that adds to the outputs and one that
> > overwrites; the latter meant to be used instead of clearing "new"
> > output buffers before using them. I'm beginning to doubt that this
> > really makes sense with today's memory bandwidth (a memset()
> > operation is very fast), but hey, you don't *have* to provide both
> > versions.
>
> I think it's not a big amount of work to provide both output
> method versions (add and replace) since only the innermost instructions
> change, but providing both methods may save us some CPU cycles.

Can be solved by putting the run() function in a spearate file and
include it twice in the main file, using different definitions of
some macros... :-)

> Therefore a plugin developer should by default supply both methods.
> (the host will be able to query if the add method is available)
>
> Any objections ?

No, I think that's the way to go. (It's not a bad idea just because
VST does it that way! ;-)

> > > For me, the idea of this API is to write something that will work with as
> > > many existing (and upcoming) programs as possible without real trauma. I
> > > deally no one should need to memcpy. The solution above at least reduces
> > > the memcpy scenario to unusual plugin coding.
> > >
> > > Thoughts anyone?
> >
> > Yes, on something slightly related: memory allocation.
> >
> > IMHO, normal plugins shouldn't use *any* syscalls or standard
> > libraries at all, except for code that links into the binary, and
> > needs nothing but the CPU and RAM. (This is to allow plugins to be
> > loaded into kernel space engines and other weird stuff, and also to
> > eliminate nasty real time problems in low latency engines.) The host
> > should provide the basic memory (de)allocation functions for plugin
> > instantiation/destruction.
> >
>
> I agree too here: we should write a guideline how to implement the DSP
> part of the plugin.

Well, actually the init and instantiation parts as well, as it'll
need to be in the same environment as the engine in most
implementations. Anything else would probably be a total mess - and
there's really no point. It's even possible to run fairly normal C++
code in kernel space without too much work, so it's no big deal,
really.

> Therefore the engine should provide as David suggested, malloc() wrappers
> (which will translate into kernel memory allocation when running in kernel
> mode).
> The allocated memory wil be mlock()ed into mem in order to provide realtime
> behaviour.

Here we have a difference between (on real time, at least)
instaniation and process time; for real time (inside
process()/run()), the rules are harder. For example, calling
kmalloc() from within an RTLinux thread will crash your kernel sooner
or later...

Further, a full generic malloc()/free() implementation calls for a
pretty complex memory manager. It must have bounded execution time
and should not generate memory fragmentation. This can be done, but
it's not very efficient use of resources, and calls for more complex
host implementations.

How about normal malloc()/free() style calls for
instantiation/destruction, and a more restricted version that can
be used from within run()/process() as well?

It's not very sexy, but wait 'till you see the result of *not* doing
it that way...

Besides, how many plugins *really* need dynamic allocation in the
run()/process() function? Traditionally, it's something you avoid
doing in time critical code, but it is possible to handle it more
efficiently than just allocating a huge "private" pool in the
instantiation or init call... If you specify what kind of blocks
you'll need at process time - preferably right in the init section,
where you register the plugin classes - you give the engine a chance
to coordinate the real time memory management for all plugins. For
example, if there are multiple plugin classes that will dynamically
allocate buffers of some 256-512 bytes, the engine could set up a
common pool of 512 byte blocks for all of them.

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