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 also fixes a bug introduced in f7c7225f5c
where the condition guarding the definition of traitCollectionDidChange
was incorrect. This function is never required if the deployment target
is at least 17.0.
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.
There were a few "ambiguous operator new/delete" errors that were due to
inheriting from a private base class that used the leak detector. These
errors are resolved by adding the leak detector to the derived classes.
JUCE_API was missing from a few useful types, notably the ARA hosting
types.
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.
When extra guarantees were added to ListenerList to guard against mutations of
the list from callbacks, it also resulted in removing a previously observable
guarantee that calls to the listeners could be made concurrently as long as
those listeners were themselves thread safe. This commit adds a new class that
restores that behaviour for anybody who needs it.
The device may need to stop because it is about to restart with new
settings.
e.g. When the DemoRunner is started while the microphone is set to
44.1KHz and the speakers are set to 48KHz in Audio MIDI Settings, one of
the devices must be restarted in order for the AudioDeviceCombiner to
work. In this situation, stopping one device shouldn't count as an
error, because the device will be started again with new, compatible,
settings.
