On Sat, Jul 2, 2016 at 1:58 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:

On Sat, Jul 02, 2016 at 09:45:48AM -0400, Paul Davis wrote:

> 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).

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.

4-8 core systems are more or less standard. So this only reduces the cost in the best possible scenario by a factor of 4-8. In more common cases, the improvement is much less.

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

Actually, I misspoke - this is already implemented. Internal clients will be executed in the same thread if they are part of a serial chain.

IMO, the reality is that chaining together entirely independent signal processing code is best done via plugins (internal clients, in a JACK context), not processes. The clever hack that JACK represents is useful for connecting small numbers of processes, but I don't believe that the design should be used as an indication that process-level chains are the right way to composite signal processing elements.