1. If AudioUnitRender return kAudioUnitErr_CannotDoInCurrentContext
within a input-only stream, the input-only stream will keep feed silence
data into the buffer instead of reporting the error. With this change,
the error will be rendered as the returned value of the data callback to
the underlying CoreAudio framework.
2. By merging the render_input into audiounit_input_callback and adjust
the timing to call reinit_async, now the reinit_async is called at the
line that is out of the main logic for feeding buffer data. In the scope
of the main logic, there will be a critical section created by locking a
Rust mutex within AudioUnitStream in the later mutex replacement.
Without moving the reinit_async, which borrows AudioUnitStream as a
mutable, out of the critical section, there will be a borrowing-twice
issue.
Differential Revision: https://phabricator.services.mozilla.com/D34064
--HG--
extra : moz-landing-system : lando
The mixer of the stream will be created, reinitialized, used or
destroyed on different threads, so its operations should be in the
critical sections. We do create critical sections by our custom mutex.
However, this custom mutex will be gradually replaced by the standard
Rust mutex in the following patches.
To replace the custom mutex, we put the mixer to the struct wrapped by a
Rust mutex and do all the mixer operations in the critical section
created by this struct. At the end when the custom mutex is removed,
those operations are still in critical sections.
Calling notify_state_changed needs to borrow AudioUnitStream as a
mutuable. To avoid the borrowing-twice issue, the notify_state_changed
calling is moved out the scope of the critical section created in the
output data callback.
Differential Revision: https://phabricator.services.mozilla.com/D34062
--HG--
extra : moz-landing-system : lando
Using an Mixer struct to operate all the mixing APIs is a way to make
the code clearer. In addition, we can avoid calling mix function by
borrowing the AudioUnitStream as a mutable. It will help to avoid
potential borrowing-twice issues in the later mutex replacement.
Differential Revision: https://phabricator.services.mozilla.com/D34061
--HG--
extra : moz-landing-system : lando
The resampler of the stream will be created, reinitialized, used or
destroyed on different threads, so its operations should be in the
critical sections. We do create critical sections by our custom mutex.
However, this custom mutex will be gradually replaced by the standard
mutex in the following patches. To replace the custom mutex, we put the
resampler to the struct wrapped by a Rust mutex and do all the resampler
operations in the critical section created by this struct. At the end
when the custom mutex is removed, those operations are still in critical
sections.
Differential Revision: https://phabricator.services.mozilla.com/D34060
--HG--
extra : moz-landing-system : lando
Using a resample struct to operate all its related operations will make
the code clearer.
Differential Revision: https://phabricator.services.mozilla.com/D34059
--HG--
extra : moz-landing-system : lando
The aggregate device of the stream may be created, reinitialized, or
destroyed on different threads, so its operations should be in the
critical sections. We do create critical sections by our custom mutex.
However, this custom mutex will be gradually replaced by the standard
Rust mutex in the following patches.
To replace the custom mutex, we create a struct wrapped by a Rust mutex
and create critical sections by this Rust mutex to do operations for
aggregate-device settings. At the end, not only aggregate-device
calls, but also other operations that needs to be locked will be
operated in the critical section created by this struct.
This is the beginning patch to replace the custom mutex in
AudioUnitStream.
Differential Revision: https://phabricator.services.mozilla.com/D34058
--HG--
extra : moz-landing-system : lando
Using an aggregate-device struct to operate all the settings for the
aggregate device is a way to make the code clearer. In addition, we can
avoid calling some aggregate-device APIs by borrowing the
AudioUnitStream as a mutable. It will help to avoid potential
borrowing-twice issues in the later mutex replacement.
Differential Revision: https://phabricator.services.mozilla.com/D34057
--HG--
extra : moz-landing-system : lando
The mutex is considered poisoned whenever a thread panics while holding
the mutex. Registering a second device changed callback without unregistering
the original callback makes the thread panics while holding the mutex
for the device_changed_callback. This mutex will be used when device
property changed callback. If the mutex is poisoned then a device
property is changed, we will get another panic when firing the callback
because of using a poisoned mutex.
Differential Revision: https://phabricator.services.mozilla.com/D34056
--HG--
extra : moz-landing-system : lando
The registration, unregistration, and notification for the device
property changed is done in a critical section created by locking our
own custom mutex. To replace our own custom mutex by standard Rust
mutex, the critical section should be created by locking a standard Rust
mutex. This can be done by simply merging device_changed_callback and
device_changed_callback_lock into a Rust mutex variable.
Differential Revision: https://phabricator.services.mozilla.com/D34055
--HG--
extra : moz-landing-system : lando
By moving out this API from the AudioUnitStream, we can avoid calling
it by borrowing the AudioUnitStream variable as a mutable. This will
help to avoid the potential borrowing-twice issues in the later mutex
replacement
In addition, the change applies an idiomatic way to wait for the system
callback event without consuming CPU time.
Differential Revision: https://phabricator.services.mozilla.com/D34054
--HG--
extra : moz-landing-system : lando
This change provides two benefits:
1. Setting variable by the Result value directly is rustier than setting
the variable by a mutual reference with a dummy Result that only
contains an error.
2. By moving out this API from the AudioUnitStream, we can avoid calling
it by borrowing the AudioUnitStream variable as a mutable. This will
help to avoid the potential borrowing-twice issues in the later mutex
replacement.
Differential Revision: https://phabricator.services.mozilla.com/D34053
--HG--
extra : moz-landing-system : lando
Setting variable by the Result value directly is rustier than setting
the variable by a mutual reference with a dummy Result that only
contains an error.
Differential Revision: https://phabricator.services.mozilla.com/D34052
--HG--
extra : moz-landing-system : lando
Setting variable by the Result value directly is rustier than setting
the variable by a mutual reference with a dummy Result that only
contains an error.
Differential Revision: https://phabricator.services.mozilla.com/D34051
--HG--
extra : moz-landing-system : lando
By moving get_volume out of AudioUnitStream, we can avoid unnecessary
borrowing from the AudioUnitStream variable. This change will make the
get_volume become symmetric to the set_volume.
Differential Revision: https://phabricator.services.mozilla.com/D34050
--HG--
extra : moz-landing-system : lando
By narrowing down the parameters that set_volume API needs, we can avoid
the unnecessary mutual borrowing from the AudioUnitStream variable. This
will help to avoid potential borrowing-twice issues in the later mutex
replacement.
Differential Revision: https://phabricator.services.mozilla.com/D34049
--HG--
extra : moz-landing-system : lando
Setting variable by the Result value directly is rustier than setting
the variable by a mutual reference with a dummy Result that only
contains the error.
Differential Revision: https://phabricator.services.mozilla.com/D34048
--HG--
extra : moz-landing-system : lando
The code will be clearer if we can wrap the state-callback that notify
the state changed into a function. It will hide some details about
rendering the callback to C interface.
Differential Revision: https://phabricator.services.mozilla.com/D34047
--HG--
extra : moz-landing-system : lando
When the stream is re-initialized, the input unit and/or output unit
should be reset if they are currently used, no matter what scope (input
or output or in-output) the parameter requests.
Differential Revision: https://phabricator.services.mozilla.com/D34046
--HG--
extra : moz-landing-system : lando
The OwnedCriticalSection is a custom mutex directly translated from the
C code of the Cubeb library. Replacing the custom mutex by standard Rust
mutex make the code fit in the Rust design better and make debugging the
code easier. The variables protected by the custom mutex in the cubeb
context is moved to the Rust standard mutex in previous patches. The
custom mutex in the cubeb context is able to be removed since we no
longer rely on it.
Differential Revision: https://phabricator.services.mozilla.com/D29983
--HG--
extra : moz-landing-system : lando
The mutex is considered poisoned whenever a thread panics while holding
the mutex. Registering a second device-collection-changed callback
without unregistering the original callback makes the thread panics while
holding the mutex for the device-collection-changed variables. This
mutex will be used when the cubeb context is dropped. If the mutex is
poisoned, we will get another panic when dropping the cubeb context
because of using a poisoned mutex.
Differential Revision: https://phabricator.services.mozilla.com/D29982
--HG--
extra : moz-landing-system : lando
The registration, unregistration, and notification for the device
collection changed is done in a critical section created by locking our
own custom mutex. To replace our own custom mutex by standard Rust
mutex, the critical section should be created by locking a standard Rust
mutex. This can be done by simply putting those varaibles for
device-collection-changed to a struct within a Rust mutex.
Differential Revision: https://phabricator.services.mozilla.com/D29981
--HG--
extra : moz-landing-system : lando
The global latency frames in the cubeb context is the latency frames of
the first cubeb stream created in that cubeb context. The reason is
because latency frames cannot be changed when there is an active stream
operating in parallel. To make sure the latency won't be changed, the
latency frames of the streams after the first stream will be overwritten
by the global latency frames. Since we always use the global latency
frames, instead of overwritting latency frames of the later streams, we
could, we could simply initialize all the streams with the global
latency frames.
Differential Revision: https://phabricator.services.mozilla.com/D29980
--HG--
extra : moz-landing-system : lando
The counting of the active streams in a cubeb context is calculated in a
critical section created by locking our own custom mutex. To replace our
own mutex by standard Rust mutex, the critical section calculating the
active streams should be created by locking a standard Rust mutex. This
can be done by simply putting the active_streams to a struct with a Rust
mutex.
Differential Revision: https://phabricator.services.mozilla.com/D29979
--HG--
extra : moz-landing-system : lando
In the current implementation, we assume the aggregate device is created
immediately after calling the system API to create it, and we also
assume the sub-devices of the aggregate device are added immediately
upon we call the system API to set the sub-devices. Unfortunately, these
assumptions are not correct. Occasionally these settings are not
executed immediately, especially when they are not called on the main
thread (e.g., we may create an aggregate device off the main thread when
switching devices). Using the listeners monitoring the devices-changed
events can make sure those settings are done.
Differential Revision: https://phabricator.services.mozilla.com/D29978
--HG--
extra : moz-landing-system : lando
The clamp_latency function is only called when the cubeb context has one
stream only. In that case, clamp_latency will clamp the stream latency
frames in a safe range and then return the clamped value directly. The
code in clamp_latency for more than one streams doesn't be executed
since clamp_latency isn't called when there are more than one streams
within cubeb context. It's easier to read the code if the unused code is
removed.
Differential Revision: https://phabricator.services.mozilla.com/D29011
--HG--
extra : moz-landing-system : lando
To import cubeb-coreaudio-rs crate later, creating a dummy folder in
advance in libcubeb. It should be the mirrow of cubeb-coreaudio-rs crate
on github. The information of cubeb-coreaudio-rs is in README_MOZILLA.
Differential Revision: https://phabricator.services.mozilla.com/D23429
--HG--
extra : moz-landing-system : lando
Pick commits:
3570749 - wasapi: tie monitor lifetime with notification client lifetime. BMO 1545279 (#505)
162625a - test: add option to get the posotion of a stream (#504)
Differential Revision: https://phabricator.services.mozilla.com/D28796
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
clang-cl only acts on five MSVC warning flags: 7219c7e9af/clang/include/clang/Driver/CLCompatOptions.td (L188-L197)
With MSVC now unsupported, most -wdNNNN have no effect and can be removed.
This patch converts the five supported warnings to their clang spellings, as preparation for a subsequent patch that will remove all remaining `[/-]w[edo][0-9]{4}`.
Differential Revision: https://phabricator.services.mozilla.com/D22582
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
