Tim Blechmann wrote:
You might examine other possibilities as well. One big one is if you have a Pentium 4 processor. I've been fighting with CPU spikes in PD for a very long time now, and often find them related to denormal numbers. These are numbers very close to absolute zero, but not quite there, and are characterized by an extremely long series of digits after the decimal point, and which kick a P4 CPU into extremely slow and accurate mode. I found the problem to be much worse under Linux, but that doesn't mean it doesn't exist under windoze.
So, i've read some of the previous postings on this, and it surely sounds like that has happened to me. I read a tip about adding noise to critical sections of the patch, but can't really figure out how much and in what kind of situations. It would be great to see a patch which does this.
one possibility is to add noise of about 1e-10 ... also the PD_BADFLOAT macro that's supposed to flush denormal numbers to zero ... but it's only killing numbers that are already denormals... i'd suggest to use the devel_0_37 branch since it contains a small patch that flushes almost denormal numbers to zero ... it helped to reduce cpu spikes on my p4 ...
Yes, you should certainly try the devel_0.37 and see if it helps you out. Dealing with denormals is quite difficult, and Intel has no plans to correct this problem any time in the future, so either people have to not buy Pentium processors for audio work, or programmers need to account for this problem in their code. Since a lot of programmers I know don't have a P4 handy to test on all the time, it makes it difficult. Trust me, PD is not the only program which suffers from denormals.
Denormals tend to happen in two places: in filters, where certain frequency componants are greatly attentuated, leading to very low sample values, and in any kind of feedback situation where the signal is attenuated over time [classic example is the tail of a reverb or delay]. Since the denormals happen *inside* the objects, you have to add whatever "safety noise" in at a point where it will remain present whereever denormals may occur, but I think it would be impossible to catch every place where you might get them. In a feedback delay patch, for example, you might have to add it *after* the attentuator for the signal which is fed back into the system.
For filters, you don't have much of a choice. The attentuation happens inside, so their code must be written to handle denormals. I know for a fact that the standard high, low and band pass filters in Miller's PD do not take denormals into account, for example. It is one of the big weaknesses of digital filters [at least on a P4], along with the possibility of "blowing up" when you run too much signal through them [see C. Roads "Computer Music Tutorial" or Boulanger ed. "The CSound Book" for big discussions on digital filters].
good luck, d.