[Jack-Devel] Compiling jack2 in mixed mode

Paul Davis 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160702/273c89e9/attachment.html>


More information about the Jackaudio mailing list