<div dir="ltr">A thing I ran into on linux: there might be some frequency scaling that is running the CPU "on demand" so it slows down if not much is going on, but it can't speed up in time to service audio interrupts. If that is the case it should be set to "performance" to force it to run full speed all the time.<br><br>Martin<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 7:21 AM, Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</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 Sat, 2014-10-04 at 13:34 -0700, Ronni Montoya wrote:<br>
> Hi, i have a very big patch that is producing glitches at 70% cpu load.<br>
> Is this normal behaivor?   With my old computer i only used to get<br>
> glitches when i go over 100 % cpu load .....any idea why its producing<br>
> 70% cpus load?<br>
> The patch has a lot subpatches and a lot of big tables with data (like<br>
> 100 tables)  ... is this a bad practice in pd?   having a lot of<br>
> subpatches, gui elements  and tables can affect the sound?<br>
> Do you think that it would be better if i put all in just one patch (<br>
> withouth too much subpatches?), and delete gui elements ? maybe are<br>
> the tables?<br>
> What do you recommend me?<br>
><br>
<br>
</span>CPU load in and glitches might correlate, but they do not so<br>
necessarily. CPU might not be the only bottle neck, there is also I/O<br>
and memory access.<br>
<br>
Even if the CPU is the culprit, there are scenarios where you experience<br>
glitches with a CPU load of 70%. What does CPU load in percent mean? It<br>
means that in a certain time frame x percent of CPU cycles have been<br>
used and 100-x percent have been idling. Assume your latency setting in<br>
Pd is much shorter than the time frame used for measuring CPU load. If<br>
you require Pd to do n calculations within m ms, this might cause an<br>
audio drop-out because the CPU is too slow, but it might still show a<br>
load of only 70% in your CPU monitoring tool, because the remaining time<br>
of the measuring window the CPU was not doing much.<br>
<br>
You can easily trigger this by something like<br>
<br>
[bang(<br>
|<br>
[100000( <- adjust that value at your will<br>
|<br>
[until]<br>
|<br>
[1.23489435(<br>
|<br>
[pow]<br>
<br>
Depending on your CPU and latency setting, you may want to alter the<br>
number in the message box in order to reliably, but only quickly cause a<br>
glitch.<br>
<br>
What you could do (combine at your will):<br>
<br>
a) make your patch less demanding at times. For instance, do not too<br>
many things in zero logical time.<br>
<br>
b) increase your latency setting<br>
<br>
c) get a faster CPU<br>
<span class="HOEnZb"><font color="#888888"><br>
Roman<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>