<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 11, 2016 at 8:24 AM, Patrick Shirkey <span dir="ltr"><<a href="mailto:pshirkey@boosthardware.com" target="_blank">pshirkey@boosthardware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
</div></div>Are we absolutely sure this is the case?  That Jonathan has not found a<br>
"bug" in JACK2 or the DSP load algorithm?<br></blockquote><div><br></div><div>the dataflow algorithm doesn't have a lot of room for bugs. but sure, yes, it is possible. however, this is easy to determine with a debug build (maybe even just a --verbose run) of JACK. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>    - reduce the amount of work done by each client.<br>
<br>
</span>According to Jonathan his multiple cores are barely reaching 5% usage. How<br>
can JACK_DSP be so high when there is so much room left to play with if<br>
JACK2 is handling the parallelism correctly?<br></blockquote><div><br></div><div>He doesn't have *that* much parallelism. He has 6 non-parallelizable stages, each one with varying levels of parallelism.<br></div><div> <br></div></div></div></div>