Hi, i have a very big patch that is producing glitches at 70% cpu load. Is this normal behaivor? With my old computer i only used to get glitches when i go over 100 % cpu load .....any idea why its producing 70% cpus load? The patch has a lot subpatches and a lot of big tables with data (like 100 tables) ... is this a bad practice in pd? having a lot of subpatches, gui elements and tables can affect the sound? Do you think that it would be better if i put all in just one patch ( withouth too much subpatches?), and delete gui elements ? maybe are the tables? What do you recommend me?
cheers
R.
Are you using [freeverb~]?
This can cause excessive CPU usage due to denormals. Try putting the [freeverb~] object in a subpatch and [switch~] off audio processing for that subpatch or add a small amount of [noise~] to the input.
Quoth Ronni Montoya, on 04/10/2014 21:34:
Hi, i have a very big patch that is producing glitches at 70% cpu load. Is this normal behaivor? With my old computer i only used to get glitches when i go over 100 % cpu load .....any idea why its producing 70% cpus load? The patch has a lot subpatches and a lot of big tables with data (like 100 tables) ... is this a bad practice in pd? having a lot of subpatches, gui elements and tables can affect the sound? Do you think that it would be better if i put all in just one patch ( withouth too much subpatches?), and delete gui elements ? maybe are the tables? What do you recommend me?
cheers
R.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
FWIW IIRC you should be able to compile freeverb with appropriate optimization flag where denormals should not affect it. On Oct 4, 2014 6:46 PM, "James Dunn" james@4thharmonic.com wrote:
Are you using [freeverb~]?
This can cause excessive CPU usage due to denormals. Try putting the [freeverb~] object in a subpatch and [switch~] off audio processing for that subpatch or add a small amount of [noise~] to the input.
Quoth Ronni Montoya, on 04/10/2014 21:34:
Hi, i have a very big patch that is producing glitches at 70% cpu load. Is this normal behaivor? With my old computer i only used to get glitches when i go over 100 % cpu load .....any idea why its producing 70% cpus load? The patch has a lot subpatches and a lot of big tables with data (like 100 tables) ... is this a bad practice in pd? having a lot of subpatches, gui elements and tables can affect the sound? Do you think that it would be better if i put all in just one patch ( withouth too much subpatches?), and delete gui elements ? maybe are the tables? What do you recommend me?
cheers
R.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Sat, 2014-10-04 at 13:34 -0700, Ronni Montoya wrote:
Hi, i have a very big patch that is producing glitches at 70% cpu load. Is this normal behaivor? With my old computer i only used to get glitches when i go over 100 % cpu load .....any idea why its producing 70% cpus load? The patch has a lot subpatches and a lot of big tables with data (like 100 tables) ... is this a bad practice in pd? having a lot of subpatches, gui elements and tables can affect the sound? Do you think that it would be better if i put all in just one patch ( withouth too much subpatches?), and delete gui elements ? maybe are the tables? What do you recommend me?
CPU load in and glitches might correlate, but they do not so necessarily. CPU might not be the only bottle neck, there is also I/O and memory access.
Even if the CPU is the culprit, there are scenarios where you experience glitches with a CPU load of 70%. What does CPU load in percent mean? It means that in a certain time frame x percent of CPU cycles have been used and 100-x percent have been idling. Assume your latency setting in Pd is much shorter than the time frame used for measuring CPU load. If you require Pd to do n calculations within m ms, this might cause an audio drop-out because the CPU is too slow, but it might still show a load of only 70% in your CPU monitoring tool, because the remaining time of the measuring window the CPU was not doing much.
You can easily trigger this by something like
[bang( | [100000( <- adjust that value at your will | [until] | [1.23489435( | [pow]
Depending on your CPU and latency setting, you may want to alter the number in the message box in order to reliably, but only quickly cause a glitch.
What you could do (combine at your will):
a) make your patch less demanding at times. For instance, do not too many things in zero logical time.
b) increase your latency setting
c) get a faster CPU
Roman
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.
Martin
On Mon, Oct 6, 2014 at 7:21 AM, Roman Haefeli reduzent@gmail.com wrote:
On Sat, 2014-10-04 at 13:34 -0700, Ronni Montoya wrote:
Hi, i have a very big patch that is producing glitches at 70% cpu load. Is this normal behaivor? With my old computer i only used to get glitches when i go over 100 % cpu load .....any idea why its producing 70% cpus load? The patch has a lot subpatches and a lot of big tables with data (like 100 tables) ... is this a bad practice in pd? having a lot of subpatches, gui elements and tables can affect the sound? Do you think that it would be better if i put all in just one patch ( withouth too much subpatches?), and delete gui elements ? maybe are the tables? What do you recommend me?
CPU load in and glitches might correlate, but they do not so necessarily. CPU might not be the only bottle neck, there is also I/O and memory access.
Even if the CPU is the culprit, there are scenarios where you experience glitches with a CPU load of 70%. What does CPU load in percent mean? It means that in a certain time frame x percent of CPU cycles have been used and 100-x percent have been idling. Assume your latency setting in Pd is much shorter than the time frame used for measuring CPU load. If you require Pd to do n calculations within m ms, this might cause an audio drop-out because the CPU is too slow, but it might still show a load of only 70% in your CPU monitoring tool, because the remaining time of the measuring window the CPU was not doing much.
You can easily trigger this by something like
[bang( | [100000( <- adjust that value at your will | [until] | [1.23489435( | [pow]
Depending on your CPU and latency setting, you may want to alter the number in the message box in order to reliably, but only quickly cause a glitch.
What you could do (combine at your will):
a) make your patch less demanding at times. For instance, do not too many things in zero logical time.
b) increase your latency setting
c) get a faster CPU
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Ivica Bukvic -
James Dunn -
Martin Peach -
Roman Haefeli -
Ronni Montoya