We are considering re-architecting our VST host in Receptor to run each plugin in a separate process and connecting the processes with Jack. How much extra overhead can we expect?
Receptor is basically a PC running our VST host. That's the only audio app that is running. Currently all the VSTs run in our host app's process, so we have no context switch or system call to get them to process. This helps keep processing overhead low. But the downsides are that (1) all plugins share the same 2GB VM space and (2) we can't make use of a machine with > 2GB RAM. (And (3) one crashing VST can take down our whole mixer, but that's another story...) As it turns out customers are interested in using Receptor to run sample players which are hungry for both VM and RAM. So giving each VST its own process would give the VST its own VM space with lots of elbow room, and allow Linux give all of those plugin apps access to the additional RAM even though they are still 32bit apps. As we looked over the Jack docs, it seems like a natural for supporting this kind of architecture. We would break out our VST support into a separate app and connect them to our Host app via Jack. This seems to be how FST is implemented and how Jack is intended to be used. So does anyone have a sense of how much overhead is introduced by the per-process() IPC that Jack uses? Our worst case would be 57 VST plugins with a 32x2 sample buffer (.725 msecs). How much extra overhead would those 57 Jack calls to process() add to the overall processing time? Any other gotchas? Thanks for any help... mo
