<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 2, 2016 at 1:58 PM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jul 02, 2016 at 09:45:48AM -0400, Paul Davis wrote:<br>
<br>
> context switches are not free. their cost varies depending on the size of<br>
> the working set of the process (the amount of memory touched by the<br>
> process, notably during the JACK process() callback).<br>
><br>
> they might vary from <10 usecs to as much as 500usecs (the lowest possible<br>
> number is dependent on your CPU; the upper bound depends on the clients)<br>
><br>
> 100 * 100 usecs = 10msecs<br>
><br>
> so, you've just used 10msecs of the time available for the process<br>
> callback. That's enormous (quite possibly larger than the actual time<br>
> available).<br>
<br>
</span>True, assuming you have single linear chain of 100 clients, and<br>
each step involves a context switch.<br>
<br>
In practice there are two factors that mitigate this problem:<br>
<br>
1. Parts of the graph may run in parallel. And SMP systems<br>
   are more or less standard today.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Linear chains could be in the same process. In that case,<br>
   depending on implementation, you don't even need a thread<br>
   switch.<br></blockquote><div><br></div><div>Actually, I misspoke - this is already implemented. Internal clients will be executed in the same thread if they are part of a serial chain.<br></div><div> <br></div><div>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.<br></div></div></div></div>