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

Kjetil S. Matheussen k.s.matheussen at notam02.no
Sun Dec 8 10:17:01 UTC 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.



-- 




More information about the Linux-audio-dev mailing list