Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la maalis 04 2000 - 20:36:50 EST
>Sorry, I used the wording "normal plugins" to mean RT plugins.
>Obviously, some systems may not be RT at all, not even soft RT!
I somehow doubt that any existing plugin for TDM, VST, DirectX or any
other API is capable of hard RT performance. People aren't writing
this stuff, and its not clear to me that they need to do so. The
hard-RT capable plugins, let alone the hard-RT requiring hosts, will
be the exception, not the rule.
>There's just one single point with my proposal of having a special
>memory management interface for instantiation/destruction: What says
>that plugin host will mlock() *all* of it's memory, just because the
>engine thread needs it?
how can the engine thread not be part of the plugin host ?
>I don't think it's a very good idea to assume that plugins will
>always be able to use the same memory allocation methods and settings
>as the rest of the application that hosts them.
certainly, but avoidance of malloc does not seem like the answer to
me. the issue really has to do with dynamic memory allocation,
period. if the plugin has to do it within the "runtime" callbacks,
there's trouble brewing.
>(Engines that want bounded instantiation times might use this as well,
>but that's not the point, although it should still be possible to
>do, IMHO. A chance of saying "this plugin can instantiate in about
>the same time it takes to process N frames of data" would be nice. If
>you don't care when writing the plugin, just ignore it. A full hard
>real time engine will either complain or work around it by
>instantiating in a separate, soft RT thread.)
whoa. instantiation, as i have understood your suggestions, is
something that happens not in response to a real-time event, but when
the user "plugs in the plugin". how long it takes is irrelevant - you
may be about to radically alter the entire data flow. nobody should
expect to be able to insert a new reverb or vocoder into the host and
not hear the effect ... what you should expect is to be able to turn
on, or fiddle with, either of them and not hear any effects (other
than the desired ones).
if instantiation refers to something closer to "voice instantiation"
in a synth, then this gets tricky: its something i tried to do for a
while in Quasimodo. its hard, damn hard if there are non-time constant
global resources that the plugin/voice may use, because the voice is
instantiated at a fixed timepoint, and the resources it uses need to
be in the correct state at that time. The main example of this is from
Csound, where function tables (sort of generalized wavetables) can
come and go, have their contents altered at certain times, etc. If you
instantiate a voice before its time, there is no guarantee that the
function table data it uses is the correct set.
i gave up. am i a pushover, or what ? :)
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST