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: su maalis 05 2000 - 20:21:02 EST


On Sun, 05 Mar 2000, Paul Barton-Davis wrote:
> >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.

That is, we're back at square one; native processing solutions will
never be usable in live situations, or even reliable enough for
serious studio recording.

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

It is, but you only have to mlock() the stuff that the engine thread
will touch. (That includes the stack...) The alternative is splitting
the application into a main process and a daemon - which does have
some advantages, like enabling the engine to survive an application
crash.

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

Yes, but generalizing eliminates any chance to solve this.

One could turn it around and say that the malloc()/free() interface
isn't allowed to be used inside the process() (or run()) call of RT
capable plugins. That means that any plugin that still wants some
form of dynamic memory management has to grab a pool during init, and
use it's own, custom memory management.

Now, wouldn't it be more efficient to provide an official interface
to an RT capable memory manager in the host, rather than using a
spearate pool for each plugin that wants to do dynamic allocation?

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

Yes, this is the way I used to look at it, and still do, most of
the time...

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

...as long as the operation doesn't stall the engine. It's very
annoying to have a dropout every time an insert effect or somenting
is replaced, the way for example Cakewalk does. I'd like to be able
to experiment without getting nervous...

But this is not real time instantiation; just "real time" changes of
the data flow without stalling the engine thread. Instantiate the
plugin in another thread, and then tell the engine to throw it in
ASAP.

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

That sounds somewhat like the usual "RT task using non-RT resources"
problem... If that happens, it's either making the global resources
entire RT capable, or redesigning the task (the plugin, in this case)
not to require that. It doesn't get more fun than that...

> 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 ? :)

Seems like you've been trying to turn a system that doesn't have a
proper distinction between non-RT (instantiation) and RT (connection,
processing) operations. Simply cannot be done in anything but the
simplest environment, if you ask me...

But why build a new system with the same problem?

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