<div dir="ltr">On Wed, Feb 7, 2018 at 9:26 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"><div class="HOEnZb"><div class="h5">On Mit, 2018-02-07 at 14:32 +0100, Lorenzo Sutton wrote:<br>
> On 30/01/2018 11:07, Roman Haefeli wrote:<br>
> ><br>
> > On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:<br>
> ><br>
> > ><br>
> > > I'm working on a patch that transmits audio through UDP. The<br>
> > > patch<br>
> > > runs<br>
> > > totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK<br>
> > > as<br>
> > > back-end. On the Linux machines I tested (all Ubuntu 16.04) with<br>
> > > the<br>
> > > same version of Pd I get a lot of glitches, although I'm using<br>
> > > very<br>
> > > similar Jack settings (128 frames/period, 3 periods).<br>
> > Update:<br>
> > My personal, somewhat outdated laptop from 2007 has absolutely<br>
> > stable<br>
> > performance with same patch, same Pd version, same OS, same kernel.<br>
> > To<br>
> > be clear: It's only Pd that performs well on one computer and not<br>
> > so<br>
> > well on others. I get glitch-free audio with Ardour on all tested<br>
> > computers. So I wonder what circumstances affect specifically Pd.<br>
> > It's<br>
> > a pity the most powerful computer I have access to is in its<br>
> > current<br>
> > state not suitable for Pd projects :-(<br>
> One thing to try from totally non-scientific personal experience<br>
> would <br>
> be to look into CPU scaling stuff when using Pd. The fact that an<br>
> old <br>
> machine works well possibly hints that this might be the culprit, so <br>
> worth trying. I experimented with this when pushing my Granita <br>
> granulator with realtime input being fed to the buffer and trying to <br>
> eliminate as much as possilbe "smart" CPU stuff improved things quite<br>
> a <br>
> lot... On my previous laptop I could set various governors on my<br>
> current <br>
> one there is only powersave and performance, the latter should work,<br>
> but <br>
> also trying to set a fixed frequency... You have to experiment a bit.<br>
<br>
</div></div>Thanks for mentioning that. Setting the governor to 'performance' for<br>
all cores is part of my standard setup when going into 'performance'<br>
mode with Pd. Even on my old laptop (CPU: Intel Core 2 Duo T8300) I<br>
need the scaling governor to set to 'performance'. To my non-scientific<br>
eye it looks like Pd in realtime mode has a higher priority than the<br>
service controlling CPU frequency, so that switching to a new frequency<br>
would happen only after Pd's need for it is over.<br>
<br>
The issue I'm having here is not related to CPU frequency scaling (at<br>
least not exclusively). Even when all cores run under 'performance' and<br>
at maximum clock speed, I get crackles with the new laptop (CPU: Intel<br>
Core i5-7300U). Yet, the only reliable way known to me so far to get<br>
running Pd crackle-free is to run four instances of 'yes > /dev/null<br>
&'. This seems to keep whatever resource Pd needs to access quickly<br>
awake and available. While those four instances of 'yes' are running in<br>
the background, it doesn't matter what governor I set since they keep </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the cores at their maximum frequency anyway. <br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Maybe there's a way to force all the Pd-related processes to run on the same core, as it could be that the transfer of memory from one to the other causes glitches, so if jackd is on a different core than Pd there will be latency as they transfer access to the buffer from one to the other. Just guessing...<br><br></div><div>Martin</div></div><br></div></div>