In shared mode (i.e. non-low-latency, non-exclusive) the driver has sole
responsibility for setting the wakeup period, and this cannot be changed
by the application. This change ensures that the audio device always
uses the buffer size reported by the audio hardware, even when that
differs from the buffer size that was requested by the program.
This reverts commit 3c1012baeb.
This change caused the AudioDeviceManager to open a fallback device if
the device name was empty, the requested number of channels was
positive, and selectDefaultDeviceOnFailure was true.
The new behaviour conflicted with the documented behaviour of
initialise(). The number of input/output channels is to be treated as a
maximum, rather than a preferred count. If a positive channelsNeeded is
requested but the device name is empty, a default device should not be
opened since the actual number of channels (0) is lower than the maximum
specified number.
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.