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: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to maalis 02 2000 - 21:11:16 EST


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

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

--p


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