Previously, the AudioProcessorPlayer would attempt to find a supported
layout that matched the audio device's output channel count, and would
force the processor to use the audio device's i/o channel counts if no
better and compatible alternative could be found.
This change allows the AudioProcessor to retain its current i/o
configuration if no better alternative can be found. This may lead to
the AudioProcessor having different numbers of inputs and outputs to the
audio device.
If there's only one audio device input, this will be copied to all of
the AudioProcessor's inputs. Otherwise, each audio device input channel
will be copied to the corresponding AudioProcessor input channel. If
there are more device inputs than AudioProcessor inputs, then some
device inputs will be discarded. AudioProcessor inputs without a
corresponding device input will be cleared/silenced.
Similar rules apply to the output channels. If there are more device
outputs than AudioProcessor outputs, then device outputs without a
corresponding AudioProcessor output will be cleared. If there are more
AudioProcessor outputs than device outputs, some AudioProcessor outputs
will be discarded.
This change improves the initialiseIoBuffers function so that it can
handle the situation where the number of processor outputs does not
match the number of system outputs, and/or when the number of system
inputs is not 0, 1, or equal to the number of processor inputs.
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.
We've already had a mechanism in place which loads these libraries, such
as libwebkit2gtk-4.1.so, only if they are available on the system during
runtime. This way we can run with either version 4.1 or 4.0 of the
library depending on which one is available.
It's also possible to run apps on headless systems with the relevant
features being effectively disabled in such situations.
wglShareLists will only succeed when the shared context is not currently
active on another thread, but it is difficult to ensure that the GL
thread is paused/inactive at any given time - in particular, it's very
easy to accidentally introduce deadlocks where the main thread waits for
the render thread's lock while the render thread waits for the
messagemanager lock.
The simplest way to ensure that no other thread has activated the shared
context is to share the contexts directly on the render thread itself.
This avoids an issue where, when attaching an OpenGLContext as a child
of a window rendered with Direct2D, the area covered by the OpenGL
renderer would display as a white rectangle until the context had
drawn a frame. This only affected the Direct2D renderer; when the parent
window used the software renderer, no white rectangle was shown.
The assertion can routinely fire on Linux, where a window may go through
many size changes from (0, 0) to its actual size due to the nature of
how XWindow reports these in subsequent ConfigureNotify events.
These subsequent changes aren't visibly observable by users.
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.
Previously, it was possible for the Timer destructor to run after the
last ScopeJuceInitialiser_GUI destructor, which meant that timer
callbacks could continue to be fired (via the appDelegate pointer) after
the static appDelegate instance had been destroyed.
With this change in place, we now ensure the Timer is destroyed before
the ScopedJuceInitialiser_GUI.
This fixes an undesired behaviour where squashing the text using
GlyphArrangement::addFittedText would only squash the visible glyphs but
not the additional kerning space between them.
