Re: [Jack-Devel] Compiling jack2 in mixed mode

Paul,

By limitations I meant not latency but various undocumented hard-coded
limits such as one with SHM and generally speaking poor error handling if
they are hit, at least in jack2. Latency is not always an issue.

My approach  also removes single router such as jackd that has to do loads
of context switches per each cycle if there are many clients and uses more
distributed approach.

But hard sync is not my requirement.

M.
02.07.2016 3:45 PM "Paul Davis" <[hidden]> napisał(a):

>
>
> On Sat, Jul 2, 2016 at 9:36 AM, [hidden] <[hidden]>
> wrote:
>
>> Hello
>>
>> I have recently made stress tests of Jack under load and above +/- 100
>> clients it starts to behave strange.
>>
>> Generally speaking it seem to not be designed for such use cases -  see
>> my discussion on this list  2-3 weeks ago.
>>
>
> every external JACK client implies at least 1 context switch.
>
> 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).
>
> JACK is quite clever, but a process-level design (i.e. context switching
> between clients) cannot scale to large numbers of clients. It would require
> entirely different OS designs (e.g. 64 bit address space with hardware
> protection rather than using an MMU) to reduce the context times to their
> bare minimum. But even then, at say 10usec per context switch, 100 clients
> is still 1 msec, which is a significant chunk of "very low latency
> settings".
>
> I don't know what you have in mind as "a replacement" but nobody who has
> worked on JACK (or related ideas) in the last decade and a half has ever
> suggested any way around this kind of limitation.
>
> Internal clients (basically, plugins) do not have this issue, since there
> is no context switch, just a thread-level switch, which is generally the
> same as a fastest-possible context switch (no MMU invalidation).  Thus, you
> can scale up better, but still not *that* high.
>
>
>

1467469713.9546_0.ltw:2,a <CA+DLCvDTjS0rDbSH2qiU3rfzY46RwCN06kg=dkiyT3PW0tsUCQ at mail dot gmail dot com>