Re: [Jack-Devel] Compiling jack2 in mixed mode

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.