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 helmi  29 2000 - 18:55:09 EST


On Tue, 29 Feb 2000, Richard W.E. Furse wrote:
> Just a thought on a potential compromise:
>
> We could keep the separation of in and out ports, but explicitly allow the
> *host* to elect to make the plugin use the same buffer for both an input
> and an output by simply passing the same buffer to two calls to
> connect_port().

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.

> #define LADSPA_PROPERTY_INPLACE_BROKEN 0x2
> ...
> #define LADSPA_IS_INPLACE_BROKEN(x) ((x) &
> LADSPA_PROPERTY_IS_INPLACE_BROKEN)

Yep. :-)

> This means that the plugin designer can make the call to break in-place
> processing if he/she wants/needs to keep things simple, but is made aware
> that he/she is doing a Very Bad Thing.

OTOH, the overhead incurred by adapting the processing code to allow
inplace processing could be for more than what is lost to extra
buffering. (As far as I can see now, this should be pretty unusual,
though...)

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

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

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