[Jack-Devel] Compiling jack2 in mixed mode
paul at linuxaudiosystems.com
Sat Jul 2 20:04:07 CEST 2016
On Sat, Jul 2, 2016 at 1:58 PM, Fons Adriaensen <fons at 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
> > 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Jackaudio