Johannes Burström wrote:
today I experienced it again, with a very simple patch - just a rather large soundfile played back by readsf~ fed into a munger~. After a sound breakdown with pd cpu usage spiking up to 97%+ i decided to defragment my drive, after which everything went as it should, and still is. so i have a few questions:
Please don't neglect the fact that munger~ is a *very* CPU intensive patch when you start to have lots of grains with very small windows. I've crashed PD many times with it [inspiring me to make my own granulating delay line instead.]
Does this (harddisc access problems = total audio breakdown) make any sense, or is it just a coincidence? after playing some live gigs with pd, i'm starting to believe in fairies and ghosts.
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.
Otherwise, yes, HD access could slow up your DSP a bit, although readsf~ is designed to minimize that much more than loading audio all at once into a table. I'll let one of the real gurus here tackle that part of your question in more detail ;-)
d.