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: la maalis 04 2000 - 12:40:32 EST


On Fri, 03 Mar 2000, Paul Barton-Davis wrote:
> [this is a resend - i pasted the address wrongly a few days ago ]
>
> David Olofson wrote:
>
> >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.)
>
> I would agree with you if a plugin was always equivalent to a unit
> generator/opcode kind of thing.
>
> But take a look at a Digidesign or VST plugin catalog at some point,
> and then tell me that none of those "plugins" ever make a system call
> let alone a library call.
>
> If you consider a plugin to be purely an implementation of a DSP
> algorithm, then this kind of restriction is OK, but I would like to be
> able to host "plugins" that can do a lot more than that. Given that
> its the user who "plugs them in", its not the responsibility of the
> host engine to be sure that it can meet RT deadlines. The host's job
> is just to execute whatever the user asked for in the right order.

Sorry, I used the wording "normal plugins" to mean RT plugins.
Obviously, some systems may not be RT at all, not even soft RT!

The point is just that there is a very sharp distinction between
hard real time capable, environtment indepentdent plugins and the
rest. Looking at what some people are asking about on places like the
RTLinux mailing list, I'd say you can't be careful enough defining
this in a clear way.

Also, the end user shouldn't end up wordering "Why do we have a
plugins standard when it takes an engineer to tell which plugins that
works with a certain engine?"

> >should provide the basic memory (de)allocation functions for plugin
> >instantiation/destruction.
>
> If you can demonstrate an MT-safe allocator faster than Hoard, I'd
> like to see it. Given that it works via a malloc interface, I think it
> safe to allow plugins to just call malloc/free, and expect the right
> thing to happen. MT-safe ? Yes, any functions offered to the plugin
> have to be MT-safe in principle, because
>
> 1) the host may need to be MT for its own reasons.
> 2) if the plugin system allows a separate thread for a GUI,
> then the plugin is MT.
>
> I think that you worry too much about the cost of malloc(). If it
> could be shown that all allocations were one of 4 sizes, I would agree
> that other methods made more sense. But plugins need good general
> purpose methods, otherwise as they evolve, they break.

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?

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.

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

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