Hi,
Im trying to use longer IRs with convolution , and cannot figure out the best solution.
(given juce now supports non-uniform partitions, many previous topics were before this)
I’m running on linux (juce 6.1) , so Ive got it using libfftw3 (see end, for a small side note on that 
)
(and I’m fixed to 48k , 128 samples for the host - no possibility to change that)
that gives me marginal improvements over the fallback fft of juce.
my understanding was with larger IRs I should use non-uniformed partitions.
e.g.
convolution_=std::make_uniquedsp::Convolution(dsp::Convolution::NonUniform { headSize });
but its a bit unclear what I can use for head size… can this exceed block size (128 samples)
as Ive noticed if I start using larger values (e.g. 512) I get audio crackling.
and it doesn’t appear to help processing load
is there generally a way to allow for larger IR sizes, at the expense of latency?
also dspProcessor spec… should maximumBlockSize = samplesPerBlock? (128)
thanks for any help…
generally I can get the dsp:convolution to work, and I can see how it can be tweaked, but it’s a bit unclear how head size for non-uniform , and latency actually affect computional load.
libfftw3 on linux, small issues using
JUCE_DSP_USE_SHARED_FFTW=1
on my distro, I had a small problem since juce_fft.cpp expects libfftw3f.so, I only have libfftw3f.so.3
is this common, perhaps juce should look for this ? as well?
(to workaround I create a sym link to fix this - and its working, but not ideal)
btw: is there a way to know which fft engine has to be loaded… it would be kind of useful to log which fit was found - I ended up editing juce_fft.cpp so I could see what was going on.