Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Benno Senoner (sbenno_AT_gardena.net)
Date: to maalis 02 2000 - 09:04:53 EST
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.
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 ?
>
> > It doesn't actually make the plugin
> > fundamentally incompatible with in-place programs as they can always
> > introduce a temporary buffer and memcpy - but this could be more efficient
> > than comparing a bunch of buffer pointers, and at least this becomes the
> > plugin writer's choice.
>
> Yes, and I think the little problem should rather be solved during
> init time in the host than during process time in the plugins.
agreed.
>
> > 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.
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.
Now it would be nice if one would write a very simple host (processing linear
chain of plugins) and a couple of example plugins (delay, simple filter) to
demonstrate the thing.
Time to open a CVS ? :-)
If you want I can host a CVS repository, or should we just use sourceforge ?
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST