15 Jun
2006
15 Jun
'06
4:17 p.m.
On Thu, 2006-06-15 at 13:59 -0400, Paul Davis wrote:
On Thu, 2006-06-15 at 10:49 -0700, Michael Ost wrote:
Since we build the hardware this is well constrained. We are using an
Athlon 2500+ in older units and a Turion ML-34 in newer ones.
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.
This could be large given that we are trying to solve the problem for
memory hungry VSTs.
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.
Sounds like our best bet would to be flexible and keep some plugins
internal and link to others (sample players) externally. That way we can
play with the costs vs benefits.
Thanks alot for your reply ... mo