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

Paul Davis paul at linuxaudiosystems.com
Thu Jun 15 17:59:52 UTC 2006


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





More information about the Linux-audio-dev mailing list