Previously, the elapsed time in nanoseconds was multiplied by 1e6
instead of 1e-6, leading to incorrect timestamps on incoming messages.
This change also DRYs the code handling time conversions between the
native/host time and JUCE timestamps (milliseconds in double format).
Even if the output stream is the only one receiving callbacks, it's
possible that the input device got disconnected, in which case we'll
still need to recreate both streams.
We now query the incoming buffers to see how many samples are available.
If the callback's buffers will fit into our preallocated buffer (i.e. the
length in samples is smaller or equal to the preallocated buffer), then
we perform an audio callback with the provided data, even if the number
of samples is smaller than expected.
If the callback's buffers are larger than expected, we split the
incoming buffer into chunks that are no larger than the prepared
buffer-size.
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.
