On Sat, Jul 2, 2016 at 1:58 PM, Fons Adriaensen <fons(a)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.