<div dir="ltr">On Wed, Feb 7, 2018 at 10:21 AM, Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mit, 2018-02-07 at 09:46 -0500, Martin Peach wrote:<br>
<br>
> Maybe there's a way to force all the Pd-related processes to run on<br>
> the same core, as it could be that the transfer of memory from one to<br>
> the other causes glitches, so if jackd is on a different core than Pd<br>
> there will be latency as they transfer access to the buffer from one<br>
> to the other. Just guessing...<br>
<br>
<br>
</span>I tried: <br>
 * turning hyperthreading off<br>
 * putting pd and jackd on the same core<br>
 * putting pd and jackd on different cores<br>
<br>
but those configurations don't seem to affect the current situation at<br>
all.<br>
<br></blockquote><div>There's also wish, the tcl/tk component.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please someone correct me here, but I think it does not matter if pd<br>
and jackd run on the same core, since they seem to communicate through<br>
/dev/shm, so there is no gain to be made by being closer together. I'd<br>
say it makes even sense to separate them so that overall more CPU power<br>
is available for both. <br>
<br>
Also, the fact the running x instances of 'yes' in the background helps<br>
indicates that the problem is not the communication between pd and<br>
jackd.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Yes it sounds like the things go to sleep when nothing happens for a few nanoseconds or something.<br></div><div>It should be documented somewhere on <a href="http://kernel.org">kernel.org</a>.<br><br></div><div>Martin<br></div></div></div></div>