A similar assertion will be added to new methods for other
ControlMessageInterface objects in a subsequent patch.
MediaTrackGraphImpl::OpenAudioInput() and
AudioListener::SendListenerEngineEvent() are two of a number of cases that
construct a ControlMessage with a null track.
Differential Revision: https://phabricator.services.mozilla.com/D191061
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
This patch allows setting the desired buffering level on AudioDriftCorrection
dynamically. If the AudioResampler's pre-buffer has not yet been set, it will
be populated to match the new desired buffering level on the next Resample().
Differential Revision: https://phabricator.services.mozilla.com/D188188
Similar to MediaTrack::mDisabledMode, but this is for uses on the
SourceMediaTrack producer thread. It is still signaled via a control message
from the control thread to maintain order of operations, and is protected by the
SourceMediaTrack mutex.
Differential Revision: https://phabricator.services.mozilla.com/D187554
This avoids putting a nested event loop on the stack, which may not unwind if
further threads are shutdown, leading to stack exhaustion.
GraphDriver::Shutdown() is called only after control of the graph has been
handed to the main thread so the graph is not running while this is called and
so MediaTrackGraphShutDownRunnable on the main thread should not need to wait
for thread shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D151357
The mInputDeviceID can be removed now since we can get the input-device
id via the DeviceInputTrackManager on the graph-thread side now.
Depends on D139444
Differential Revision: https://phabricator.services.mozilla.com/D139445
This patch creates a class to manage all DeviceInputTracks in one place,
which simplify the code in the MediaTrackGraph.
Depends on D138726
Differential Revision: https://phabricator.services.mozilla.com/D139444
Separate common interfaces that will be used for NonNativeInputTrack
class, from NativeInputTrack, into a base class: DeviceInputTrack, where
the NonNativeInputTrack will be implemented in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D137782
We are going to call `AudioInputProcessing::SetRequestInputChannelCount`
in the following patch (D136922 in bug 1751963), which will call
`MediaTrackGraphImpl::ReevaluateInputDevice`, via
`MediaEngineWebRTCMicrophoneSource::ApplySettings` before starting the
`AudioInputProcessing` and creating an `AudioCallbackDriver` in
`MediaTrackGraph`. It makes sure the input-channel count meets the current
user preference before starting the audio device and the audio
processing. However, if the current `GraphDriver` is not a
`AudioCallbackDriver` when `ReevaluateInputDevice` is called, we will hit
an assertion. To allow setting the correct input-channel count before
starting the audio device, we need to replace the assertion to an if
statement.
Differential Revision: https://phabricator.services.mozilla.com/D136795
The `AudioInputTrack` is renamed to `AudioProcessingTrack` in D134629,
in Bug 1742655, so the `AsAudioInputTrack` should be renamed to
`AsAudioProcessingTrack` as well.
Differential Revision: https://phabricator.services.mozilla.com/D137319
Move the audio-opening check logic and the creation of NativeInputTrack
in one place instead of seperating them in different functions. This
reduces the complexity of audio-opening logic in MediaTrackGraph and
make it easier to test.
Depends on D134627
Differential Revision: https://phabricator.services.mozilla.com/D134533
Implement utility functions to query the input channel count and whether
input has voice from NativeInputTrack's users
Depends on D134527
Differential Revision: https://phabricator.services.mozilla.com/D134532
mDeviceTrackMap only has one element since MediaTrackGraph can have only
one input device. Besides, we can get NativeInputTrack directly from
mTracks on graph thread without accessing it from mDeviceTrackMap. The
only left reason for having mDeviceTrackMap is to check if we have any
input device on Android. On Android, the default input device id is
always nullptr, so we use a hashmap to check if MediaTrackGraph contains
any input device. However, this hashmap can be replaced by a RefPtr
storing the MediaTrack for the input device since MediaTrackGraph can
have only one input device.
Depends on D134530
Differential Revision: https://phabricator.services.mozilla.com/D134527
