<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 10:53 AM, Markus Seeber <span dir="ltr"><<a href="mailto:markus.seeber@spectralbird.de" target="_blank">markus.seeber@spectralbird.de</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 04/07/2016 01:57 AM, Robin Gareus wrote:<br>
><br>
> How would that effectively differ from running at twice the buffersize?<br>
><br>
> That approach just moves the load to two CPU cores. If those two cores<br>
> can produce the result in a given time, a single core can do the same<br>
> with twice the buffersize. Identical total latency.<br>
><br>
> 2c,<br>
> robin<br>
<br>
</span>This is called interleaved scheduling and gives a scheduler the option<br>
to run tasks in parallel by interleaving two (or more) process cycles.<br>
This differs  from using a double buffer size because the scheduler has<br>
more opportunity to fill "holes" in the schedule, that are introduces by<br>
client dependencies in the graph.<br>
<br>
Doing this by hand (as described by bridiging multiple jack instances)<br>
moves the responsibility of interleaving the two jack schedules to the<br>
kernel scheduler and may theoretically bring better resource usage in<br>
some special cases, but also has some pitfalls.<br></blockquote><div><br></div><div>given that a process callback should NEVER enter the kernel or use any user-space blocking mechanisms, the only way this could possibly help is dealing with transitions between clients. it could NEVER result in better performance if kernel scheduling intervened within a single client's process callback.<br><br></div><div>but ... jack2 already runs multiple threads, and will activate clients on separate cores when appropriate. so JACK2 already does this, which is why those of us who have been around the block on this for quite some time are bit skeptical about jonathan's "experiment". <br><br></div><div>i once considered submitting a paper to Usenix about JACK because if you forget about audio+MIDI entirely, it still represents a rather interesting case of user-space scheduling being *more* optimal than anything the kernel can do. In the 90's i worked a little on what was then a fairly radical kernel scheduling design ("scheduler activations") that attempted to get the benefits of both kernel scheduling and user space scheduling. in some respects, JACK (even JACK2 itself, which brings a whole additional layer of scheduling complexity that I had nothing to do with) represents some of we learned during the experiments with SA on a real OS, even as it points out the desirability of a new system call that hands the processor to another thread directly rather than relying on intermediate objects like futexes.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The right way to to this, would be to implement this in the sound<br>
server, </blockquote><div><br></div><div>jack (1 or 2) *is* the sound server. there is no kernel sound server. and if there was, there's no evidence it could any better job than jack does, other than doing direct handoff from thread to thread without relying on futex/fifo wakeups. <br></div><div> </div><br></div></div></div>