[linux-audio-dev] Jack's IPC overhead

[Michael Ost]

On Thu, 2006-06-15 at 13:59 -0400, Paul Davis wrote:
> 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:

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.

> 	(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