We recently upgraded to JUCE5.4.3 (from JUCE4.2.4) and encountered an issue with Garageband iOS when using the Guitar / Strings / Bass instruments (works fine on all other hosts and even on the keyboard instruments and audio tracks on GB).
AudioProcessor::prepareToPlay gets called twice. The first call reports a sample rate of 44100 Hz and 128 samples buffer size, and the second time it reports a sample rate of 22050 Hz with a buffer size of 1024 samples. The process callback requests a 128 samples buffer (at 44.1kHz I assume). We’ve been relying on that last sample rate reported in prepareToPlay will be a valid one, but in this case it’s not.
We noticed this because the plugin we’re currently working on doesn’t support sample rates below 44.1kHz. Haven’t really investigated how stuff behaves in JUCE4, but the same plugin code works fine when using the older JUCE 4.2.4 modules.
The first call to
prepareToPlay() comes from the
init() method in the AUv3 wrapper and uses
kDefaultSampleRate which is set to 44.1kHz. The second call will be with the actual sample rate retrieved from the bus objects in the
allocateRenderResourcesAndReturnError() method so this is the one that is correct. The smaller buffer size is not unexpected as the size given in
prepareToPlay() is a maximum buffer size and the host can call your process method with a smaller size so you need to write your
processBlock() in such a way that it can deal with chunked buffers.
Thanks. Yes, the stream is 22.05kHz, just checked with a filter. My mistake. JUCE4 never seem to report this sample rate in prepareToPlay though; I’m getting 44.1kHz both times prepareToPlay is called, even if the actual stream is 22.05kHz.
Yeah, it seems like the old AUv3 wrapper wasn’t reporting the actual sample rate of the buses correctly but the new value should be the correct one.
Wow, thanks for this thread. I was so confused as to why I was only getting 22.05kHz in some plugin instances in a GarageBand session.