[linux-audio-dev] Plugin server (Re: [vst-plugins] Re: [a bit OT] gcc as a cross compiler for VST? - Linux-audio-dev

8 Dec 2002

Please follow-up this discussion to LAD.

On Sun, 8 Dec 2002, Paul Davis wrote:

...
    the situation, as i said before, is miserable. we just
don't have a
 situation in linux where a single point of control can say "*this* is
 the GUI toolkit you will use". X is clearly the standard, but its not
 a toolkit (see below) that anyone can feasibly use alone.
 I have asked you this two times allready, but I'm trying for a third time
now. Why do you need this functionality? Unix is built from the ground
to support multiple processes running at the same time, and therefore does
it very well, at least linux does. And unix has things as sockets, pipes,
semaphores and shared memory. WHY do you need to run everything from the
same process? I only see disatvantages by doing that, exept that it
uses a tiny bit more memory, but thats it. Please explain to me... 
 because when running a real-time low-latency audio system, the cost of
 context switches is comparatively large. if you've got 1500usecs to
 process a chunk of audio data, and you spend 150usecs of it doing
 context switches (and the cost may be a lot greater if different tasks
 stomp over a lot of the cache), you've just reduced your effective
 processor power by 10%.
 I dont believe you. I just did a simple context-switching/sockets
test after I sent the last mail. And for doing 2*1024*1024 context
syncronized switches between two programs, my old 750Mzh duron uses 2.78
seconds. That should about 1.3usecs per switch or something. By
having a blocksize of lets say 128 bytes, that means that by
25 minutes of 44100Hz of sound processing, 2.78 seconds is used
for context switching. Not much.

I'm not talking about jack tasks, I'm talking about doing a simple plug-in
task inside a standalone program, the way the vst server works.

I believe the advantages of making a proper plug-in server with an
easy-to-use library binding "plug-ins" and hosts are large:

1. Stability. A Host can not crash, the server can not crash. Just the
   plug-in can crash.
2. Runs better on multiprocessor machines. (At least I think so)
3. Ease-of-use. By extending the interface with a library, common tasks
   as finding lists of plugins, loading plug-ins and GUI is available
   as functions ready to use.
4. A "plugin" is a program, which means that it can choose whatever GUI
   system it wants. Ladspa plug-ins can use guis.
5. All sorts of plugins can be supported by one such system, vst, ladspa,
   DX, maya, etc.
6. By making a simple wrapper, all ladspa plugins can automaticly be
   available as a "plugin" server "plugin", serving GUI.

-- 