15 Jun
2006
15 Jun
'06
4 p.m.
On Thu, 2006-06-15 at 10:49 -0700, Michael Ost wrote:
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?
sounds like a bad idea (for this number of "entities") in general, but
it might work.
its not possible to provide actual numbers, because its totally
dependent on (a) CPU architecture and (b) CPU speed. there are two
costs:
(a) actual context switch time, determined by CPU speed
and CPU architecture (number of registers to be
saved, etc)
(b) TLB invalidation overhead caused by the context switch
the cost for (b) depends on the working set size of the execution
context on each side of the switch. there's no way to answer how much
this can be without measurement.
however, i would be reasonably sure that at 32 frame/period, the
overhead of these context switches is going to cost *a lot* as a
percentage of the overall cycles available for processing.
i would still advocate on behalf of JACK, however: run the existing FX-
centric plugins inside an internal JACK client (i.e. a JACK "plugin")
or a single external JACK client, then run the sample players etc as
external JACK clients just as FST does.
--p