Starting with DSPModulePluginDemo (incidentally I now can’t find the download link), I added android as a build target, opened with Android Studio (Windows 10) and changed build variant to release. On my Samsung Galaxy S7 running Android 8.0 audio is processed cleanly until I enable ‘Cabinet Sim’ which causes the dsp::Convolution to be included in the processing chain and the audio glitches badly. I’m assuming the audio isn’t getting processed quickly enough but have no non-rooted way that I can find to check the CPU usage.
Before I start figuring out how to set buffer sizes can anyone confirm that they have had this working, perhaps on other devices. I realise latency is generally poor on android but it would be nice to know that dsp::Convolution processing is viable.
Convolution is very intensive so it’s not that surprising. Try a smaller impulse size and a larger buffer size and see if it improves things.
So digging a bit deeper…
I have synth plugin code which just generates random noise, duplicates the audio into the second channel and does a stereo convolution using a 255-tap impulse response (48 kHz sample rate) compiled as a standalone app for different platforms. Here are some values reported by
Platform/Hardware Buffer size CPU [%]
Windows 10 (i7) 256 <5
Mac (i7) 512 <1
iOS 12.3 (iPhone 6) 256 <2
Android 8.0 (Galaxy S7) 4800 100
Android 6.0 (Nexus 5) 1920 100
Android 6.0 (Nexus 7) 1920 90-100
I realise my sample of android devices is pretty old, but I find it hard to believe that they are that bad.
I’d be very interested to hear from someone who has had good results using dsp::Convolution on any flavour of Android!
I guess you have compiled in release mode?
What FFT engine did you use?
JUCE utilizes the fast convolution -> in frequency domain. So FFT and IFFT are needed to do the frequency transformations. On Mac (and I guess also on iOS), JUCE uses the Accelerate framework, which is quite fast. On other platforms, JUCE uses the fallback engine per default, which is very very slow. That might explain the results.
Engines compatible with JUCE’s dsp::Convolution are FFTW and Intel MKL.
Yes, compiled in release mode but I didn’t touch anything to do with fft engines. The fact some platforms are accelerated out-of-the-box and others not would definitely explain things. I’ll dig into that. Thanks for the pointer.
just wanna throw in here - profile with a profiler! The
getCpuUsage method is telling you there’s a bottleneck, not what the bottleneck is. This is important especially when comparing performance differences between platforms.