Hi, I have a patch that is using rfft, similar to the phase-vocoder tutorial patch. It is operating accurately and reliably until I use a large window size while have a number of instances running at once. Then I start getting crackling sounds that sound to me like audio dropouts.
When I use the cputime object, it looks like I'm well below the threshold for where I would expect problems (hovering around 20%). Activity Monitor/Task Manager shows about 20% as well, and the total cpu load is low.

I am not surprised that there are artifacts when I have too many instances of the patch running at once, but I'm surprised that it doesn't show up as cpu overrun. Are there other diagnostic tools I can use that would help me predict when I will start to hear arifacts?
thanks

I'm not sure that the fft has anything to do with it, except that I haven't otherwise had dropouts without high cpu usage.

Can you share your patch?

Thanks for replying. It's part of a pretty large project and woud be hard to isolate, but I've reproduced the dropouts with something simpler:

fftDropoutExample.pd

It is literally the phase vocoder tutorial patch with a whole bunch of extra fft-analysis windows running simultaneously. my cpu is at 16% but there are loud clicks at random intervals.

@mbbaker For me the patch is fine.
I set the window size to 16384 and there are no dropouts with cpu reported as 21%.
With your windowsize of 4096 cpu reports as 3.1% so my laptop might be more powerful though.

You could change the [block~] setting to [set $1 2( for double overlap rather than quadruple.... which will relax the processing a little (in [pd fft-analysis]... )
You would have to do that in every copy as it is a sub-patch rather than an abstraction.
The message already slows processing as the windowsize increases... .but maybe not enough for your setup.

Although I doubt that it could help you could try increasing the additional buffer to the soundcard by the Delay (mSecs) setting in Media audiosettings.
@alexandros will know more than me......
David.

@whale-av I think you got this covered much better than what I would! Honestly, I really don't know why you think I would know more than you..

@alexandros Because you do...... I make errors and bad assumptions, and know next to nothing about fft.
David.

Actually, raising the window size should drop the CPU usage. I tried your patch on my laptop, and with a 4096 size, I got a 13% CPU. while with a 16384 size I got 10%. With a 2048 size I got around 17%. I didn't get any dropouts or crackling sounds at all. Are you outputting all the subpatches at the same time? If so, did you try to lower the volume of these sub patches? It could be that they are exceeding the audio range and there is distortion there, but I doubt that this is really the problem. Other than that, I think @whale-av gave all the help possible.

@mbbaker I don't hear dropouts either ... But I noticed, that you forgot to delete the [tabsend~] objects in copy no. 7. Not sure if this is (or should be?) a problem. Since Pd doesn't complain about it, I guess probably not.

@whale-av said:

Although I doubt that it could help you could try increasing the additional buffer to the soundcard by the Delay (mSecs) setting in Media audiosettings.

Actually, that was my first thought. I once used a simple patch to document what the minimum delay times and buffer sizes were for each of my computers and audio interfaces, but later discovered that I couldn't use those minimum values for more complicated patches.

@jameslo Interesting...... worth remembering.
@spacechild1 ? why?
David.

Thanks for all the thoughts!
@whale-av @jameslo you were right about the audio delay. Increasing from 5 of 8 ms did the trick!

Reading a bit, it seems that 50 is the default. I have no idea how mine ended up so low. My laptop isn't so old, and I was a bit surprised that everybody was getting better results than me haha. Anyway, I'm going for responsive, so I'll keep it as low as I can without getting those dropouts. Thanks again