Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Benno Senoner (sbenno_AT_gardena.net)
Date: su maalis 05 2000 - 08:33:13 EST
On Sun, 05 Mar 2000, Paul Barton-Davis wrote:
>
> >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.
Agreed.
I think that almost all plugins existing on the various plugin APIs
(VST etc), will not call malloc() and friends within the DSP loop.
My goal is to provide an API which allows to plug and unplug
the various without causing any audio disruptions.
That means that we need to call all non-deterministic fuctions
like malloc() etc in a separate thread in the host which runs
without RT privileges.
This way the RT host will run troublefree, and
since we are using threads the memory is shared among the
RT thread and the non-RT thread of the host.
As soon the instantiation is done (memory is allocated etc), the plugin can be
added to the processing chain without causing audio disruptions.
The same applies to the removal of plugins.
Just delegate the non-deterministic init/exit phase to the non-RT thread of
the host and the game is done.
> 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).
Yes , exactly, and I am not sure if VST can guarantee this.
But for MuCoS wewill provide this feature, since it's not a big deal.
( Basically the simplest way would be to ALWAYS call the
init/cleanup functions from the non-RT engine-thread,
and forbid non-deterministic syscalls within the DSP part of the plugin)
>
> 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 ? :)
The synth should not allocated the memory dynamically,
alloc at init time and then provide a maximum number of N voices.
Even if we would provide a hard-RT malloc() we would have to
alloc and mlock() the memory in advance, thus effectively "wasting" it.
If you want to trigger certain actions during the song,
like loading a new instrument from disk (MIDI program change) during a song,
the only way I see is to instantiate-ahead,
this will work for sequenced data but not for live performance.
If you want live performance you have to keep the data in memory.
Or at least the initial part for the disk-based sampler approach.
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST