On Sat, Jul 2, 2016 at 9:36 AM, marcin(a)saepia.net &lt;marcin(a)saepia.net&gt; wrote: every external JACK client implies at least 1 context switch. context switches are not free. their cost varies depending on the size of the working set of the process (the amount of memory touched by the process, notably during the JACK process() callback). they might vary from <10 usecs to as much as 500usecs (the lowest possible number is dependent on your CPU; the upper bound depends on the clients) 100 * 100 usecs = 10msecs so, you've just used 10msecs of the time available for the process callback. That's enormous (quite possibly larger than the actual time available). JACK is quite clever, but a process-level design (i.e. context switching between clients) cannot scale to large numbers of clients. It would require entirely different OS designs (e.g. 64 bit address space with hardware protection rather than using an MMU) to reduce the context times to their bare minimum. But even then, at say 10usec per context switch, 100 clients is still 1 msec, which is a significant chunk of "very low latency settings". I don't know what you have in mind as "a replacement" but nobody who has worked on JACK (or related ideas) in the last decade and a half has ever suggested any way around this kind of limitation. Internal clients (basically, plugins) do not have this issue, since there is no context switch, just a thread-level switch, which is generally the same as a fastest-possible context switch (no MMU invalidation). Thus, you can scale up better, but still not *that* high.

On Sat, Jul 02, 2016 at 09:45:48AM -0400, Paul Davis wrote: possible True, assuming you have single linear chain of 100 clients, and each step involves a context switch. In practice there are two factors that mitigate this problem: 1. Parts of the graph may run in parallel. And SMP systems are more or less standard today.

2. Linear chains could be in the same process. In that case, depending on implementation, you don't even need a thread switch.