The code added in 6f20de5434 was only
executed when no explicit sample rates were set.
Now, the sample rate is always updated after querying available sample
rates and before querying available buffer sizes, so that the buffer
size check is guaranteed to use an up-to-date samplerate value.
This fixes a bug on iOS 17 running on a 9th gen iPad.
- Set JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES=44100,48000,88200,96000
- Start the DemoRunner.
- Add a breakpoint in AudioDeviceManager::audioDeviceAboutToStartInt().
- In the DemoRunner, change the sample rate to 96000.
- The breakpoint will fire. Observe the value of
getCurrentBufferSizeSamples().
- Move the breakpoint to audioDeviceIOCallbackInt and continue
execution.
- The breakpoint will fire. Observe the value of the numSamples
parameter.
numSamples should always be no larger than the sample count reported in
audioDeviceAboutToStartInt().
Before this change, it was possible for getCurrentBufferSizeSamples() to
return a value smaller than the buffer size of subsequent process
callbacks.
Removing the availability checks and unconditionally
deactivating/reactivating the device seems to fix this issue, and the
correct buffer size is returned immediately when the device is
(re)started.
The waiting is only added on iOS 18 as this is the only platform where
seems to be an asynchronous relationship between
(1) AVAudioSession setActive:
(2) AVAudioSession setPreferredIOBufferDuration:
and (3) AVAudioSession.IOBufferDuration.
The issue is not observable in the iOS 18 emulator.
