Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: est_AT_hyperreal.org
Date: pe elo 27 1999 - 14:58:12 EDT
David Olofson discourseth:
>
> > * The only global defined by a plugin should be a uniquely named
> > function that returns a plugin class. The idea here is to make it
> > possible to use static as well as dynamic linking.
>
> Nope. For kernel modules, it only makes sense to export init_module()
> and cleanup_module(), and init_module() has to
> register_plugin(&audioeff_class) to tell the engine about the new class.
> This eliminates name space conflicts, as no symbols are exported. Also,
> a module/library can register multiple plug-in classes this way.
Ah..but that still precludes static linking.
> > * String parameters should be provided for.
>
> On the contrary, as much as possible of the not directly signal
> processing related stuff should be kept *out* of the DSP part of the
> plug-on spec.
I think this is totally true for many plugins. However, some plugins
will *be* gui elements. Some will even use (shhh) files. :O These are
inappropriate for use in rtlinux, but they represent important audio
processing that many on this list are involved in.
> > * We need a flag to say whether a parameter can be modified in between
> > any two calls to the process method as opposed to being settable only
> > for initizlization purposes.
>
> Hmm... My plans are very different. I don't want parameters in the low
> level plug-in spec at all. There should be only time stamped events and
> data streams. Parameters are realized through an event based interface,
> which means
>
> 1) Only one interface + subsystem for automation, MIDI-style
> events and system control events.
>
> 2) Events and parameter changes are independent of buffer sizes.
>
> 3) *Everything* can be defined in relation to real time.
> (A way for plug-ins to tell the engine which events they
> support, and their real time characteristics is needed.)
Hmm..this sounds interesting but radically different from the approach
Guenter is taking. Perhaps you should write up a competing proposal?
> > * The number of channels per input and output signal should be a
> > plugin property vector. Counts of frames and samples should be
> > clearly distinguished throughout.
>
> IMHO, input and output signal should always be mono, because anything
> else completely breaks the flexibility of free signal routing. Unless
> you automatically throw in split/merge plugs where needed... I don't
> think that's a good idea from the performance perspective.
>
> OTOH, there might be a point in using multichannel bus formats for some
> kinds of plug-ins, so supporting it isn't a bad idea. It can result in
> faster code as long as everything fits nicely together.
Ahh..thanks! I need support here. :) I certainly agree that mono is
great for flexibilty.
> The basic rule is that the engine gets to decides what sample rate to
> use. Complex processing nets with plug-ins that have various smart ideas
> about what sample rates to use just becomes a mess of lost quality and
> CPU power...
Sounds good to me. Does anyone really want sr-specific plugins?
Perhaps for i/o purposes?
> > * To handle resampling, variable output buffer sizes are important.
> > It's also important that the process method can report how many output
> > frames it generated (is this the function of the return value of the
> > process method?). It may even be important that the plugin can
> > be queried as to how many output frames *will* be generated to avoid
> > overruns due to disagreements about fencepost issues.
>
> DO NOT adapt output buffer size to the inputs!!! It's doing it all
> backwards.
OK, I was on crack when I wrote that. Honestly, I've always coded to
the give-me-this-many-output-samples paradigm so I have no idea what I
was thinking.
> The algorithm is: "I need X samples. How many input samples do you need
> for each channel?"
>
> That's what this section of my little draft is for:
>
> int look_ahead; /* Number of extra frames needed
> * after the end of input buffers.
> * Can be negative.
> */
> int skip_behind; /* Number of frames skipped
> * at the start of input buffers.
> * (That is, inputs[n]+=look_behind
> * before process_XXX() is called.)
> * Can be negative.
> */
Can you expand on this? I'm slow. :)
> > * The popup method should probably be expanded to a vector of generic
> > gui methods.
>
> Nope. Drop it completely. There's no reason at all to have it in the
> same file as the signal processing code.
Well, audio processing isn't all about core dsp. I've covered this in
a separate post. I think that you can be confident that there will be
plenty of pure dsp plugins, however, and I agree that the spec must
provide for such.
> > * Memory allocation hooks are probably desirable. That way I can get
> > a plugin to throw bad_alloc even if it know nothing about C++.
>
> Yes, indeed. Also, it has to be strictly defined *when* you can allocate
> and free memory, as it's not real time operations.
Hmm..what kind of predicates would be useful? Perhaps
allocs_only_at_init() and alloc_is_param_independent() might help? I
think those would be true of many, many pure dsp plugins. They could
default to false for plugin authors who don't think about such things.
> It's possible to
> design a fast, non fragmenting real time memory manager with a locked
> memory pool for those who really need it, but dynamic allocation is
> generally considered a no-no in hard real time systems.
I think many pure dsp plugins would work fine using a no-op free().
Just sequentially allocate all their init stuff in a statically
allocated arena.
A tangential question re fragmentation: isn't there always some in a
malloc()/free() paradigm (assuming your free() does something)? For
example, what's the minimal safe-for-space factor for a buddy-block
system?
Thanks for being involved, :)
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST