I have the same problem (using juce 5.3.2). About 5-10% of the time when I load my plug-in I get dead output channels caused by NaNs. I’ve removed all my own code apart from the call to Convolution::process() and I still have the problem, which makes me think that this isn’t a memory fault that I’ve introduced.
Just like the OP, I’ve verified that the input data to ConvolutionEngine::processSamples() is good and that the problem starts with a single NaN on the input to FFTFallback::performRealOnlyInverseTransform().
I believe that the problem is in ConvolutionEngine::updateSymmetricFrequencyDomainData(). It seems to me that outputData points to 2*FFTSize floats but that it contains only (FFTSize + 1) real value floats when it’s passed to updateSymmetricFrequencyDomainData(), due to this line:
FloatVectorOperations::copy (outputData, outputTempData, static_cast (FFTSize + 1));
updateSymmetricFrequencyDomainData() turns these (FFTSize + 1) real values into 2*FFTSize floats, which are interpreted as FFTSize complex numbers when passed to performRealOnlyInverseTransform(). The problem is that updateSymmetricFrequencyDomainData() does not write to the real value at index (FFTSize + 1) - this is the imaginary component of the middle value of the FFT, which (due to conjugate symmetry) should be 0 if the FFT is even order and of a real signal.
updateSymmetricFrequencyDomainData() contains the line:
samples = 0.f;
which is apparently ensuring that the DC component of the FFT is real, but if FFTSize is even then the same needs to be done to the middle value of the FFT. i.e.
samples[FFTSize + 1] = 0.f;
Since outputData[FFTSize + 1] is not written to explicitly, and bufferOutput is not initialised to zero when setSize() is called on it, its value will be uninitialised rubbish, which may or may not be NaN. This would explain why the bug is hard to reproduce.
I’ve verified (as best I can) that zeroing that extra element fixes my problem, but I’d welcome any input as I’m working to a release deadline and this is quite a serious bug for us. The comments for updateSymmetricFrequencyDomainData() imply that it’s reversing another method, prepareForConvolution(), so it may be that the proper fix needs to look at that method too. Also if FFTSize is odd, I guess that the extra element shouldn’t be zeroed…
Thanks in advance!