Unittests using GoFaster mode may start iterating the audio driver faster before
its fallback has completed handover to the audio callback. This causes the
preSilenceSamples check to spike and the test fails.
Waiting for the fallback to finish handing over fixes this.
To accomodate this, this patch also constifies some methods as needed to check
InIteration() when const.
Differential Revision: https://phabricator.services.mozilla.com/D97413
Unittests using GoFaster mode may start iterating the audio driver faster before
its fallback has completed handover to the audio callback. This causes the
preSilenceSamples check to spike and the test fails.
Waiting for the fallback to finish handing over fixes this.
To accomodate this, this patch also constifies some methods as needed to check
InIteration() when const.
Differential Revision: https://phabricator.services.mozilla.com/D97413
Unittests using GoFaster mode may start iterating the audio driver faster before
its fallback has completed handover to the audio callback. This causes the
preSilenceSamples check to spike and the test fails.
Waiting for the fallback to finish handing over fixes this.
To accomodate this, this patch also constifies some methods as needed to check
InIteration() when const. It also waits for audio drivers to start per the above
in TestCrossGraphTrack as that test may otherwise exhibit this bug with bug
1605314 applied.
Differential Revision: https://phabricator.services.mozilla.com/D97413
When opening a second input track, there will already be some data from its
first instantiation in the driver's scratch buffer. If we ignore this data, we
end up buffering too much in AudioInputProcessing::Pull and tripping an assert.
Differential Revision: https://phabricator.services.mozilla.com/D95939
Without this patch, AudioInputProcessing wouldn't be aware of an audio driver
changing to another driver, be it a system driver or an audio driver that starts
on its fallback.
It could fail an assert since neither of those new drivers would append any
input data, so AudioInputProcessing would run out of buffered data but not know
to reset the state doing the bookkeeping for this.
Differential Revision: https://phabricator.services.mozilla.com/D95938
This patch changes the type of mAudioThreadId because `std:🧵:id` is
non-memovable and AudioThreadRegistry uses an nsTArray, that needs elements to
be memovable.
Differential Revision: https://phabricator.services.mozilla.com/D80466
The key change here is that AudioContextOperation promises for the same
AudioContext are resolved in order as long as the graph is running.
There is one remaining case where AudioContextOperation promises can be
resolved out of order, which is when
AudioContextOperationControlMessage::RunDuringShutdown() resolves a Close
operation shortly after Run() has queued its update via mUpdateRunnables.
mUpdateRunnables are run after controlMessagesToRunDuringShutdown.
https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/dom/media/MediaTrackGraph.cpp#1793,1803
Pending resume operations are now stored on the graph instead of on
mNextDriver. This means there is no need to move operations between drivers
when switching from one mNextDriver to another, the code for which was
previously missing.
Suspend operations are performed immediately, because even a callback driver
can render nothing. Tracks are not resumed until either there is an
AudioCallbackDriver to deliver the rendered audio or the Resume operation is
canceled by a subsequent Suspend.
While the graph is running, DispatchToMainThreadStableState() is used
consistently, whereas previously this was mixed with direct Dispatch() to the
main thread, which could have the runnable Run() before main thread state had
been updated for rendering up to the time of a Suspend.
Differential Revision: https://phabricator.services.mozilla.com/D76806
We're doing it async, triggered during the stable state runnable, and then the
values are cached in atomic variables, so that the rendering thread can have the
info as well, for using during processing.
Differential Revision: https://phabricator.services.mozilla.com/D75331
Till now an AudioCallbackDriver, on error state callback, creates a FallbackDriver, which attempts to start the existing AudioCallbackDriver. If the driver has already started this creates a cr
ash because restart is not allowed.
This patch continues using the FallbackDriver, on cubeb state error but the driver has been enhanced with an error state that will not attempt to restart the driver. The fallback driver will continue advancing the graph similar to a ThreadedDriver until a driver switch takes place.
Depends on D73102
Differential Revision: https://phabricator.services.mozilla.com/D73103
This will allow OfflineClockDriver to obtain an nsIThreadObserver from the
GraphInterface when it is a MediaGraphTrackImpl.
Depends on D65070
Differential Revision: https://phabricator.services.mozilla.com/D65071
--HG--
extra : moz-landing-system : lando
Since we now run a fallback driver while an AudioCallbackDriver starts, this has
exposed a path where the double-append-during-iteration assertion fails.
It seems to happen at least when there's an audio->audio driver switch, and a
fallback driver was running in between.
The state for this assertion assumes it's reset when the AudioCallbackDriver
that's feeding it starts, but forgot to account for driver switches and
fallbacks, which could still cause silence to be pulled for the track.
Differential Revision: https://phabricator.services.mozilla.com/D57037
--HG--
extra : moz-landing-system : lando
Note that this will only switch to the fallback driver once, and never switch
back. This will improve in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D56083
--HG--
extra : moz-landing-system : lando
This makes it simpler to maintain state in the GraphDriver in more complex
cases, such as when an AudioCallbackDriver is backed by a fallback driver.
Differential Revision: https://phabricator.services.mozilla.com/D57553
--HG--
extra : moz-landing-system : lando
This lets us iterate more things than MediaTrackGraphImpl, e.g., audio drivers
(from the fallback driver) and unit test classes.
Differential Revision: https://phabricator.services.mozilla.com/D56082
--HG--
extra : moz-landing-system : lando
This will let us get rid of such GraphDriver dependencies on MediaTrackGraphImpl
as SignalMainThreadCleanup and SetCurrentDriver.
Differential Revision: https://phabricator.services.mozilla.com/D56076
--HG--
extra : moz-landing-system : lando
This removes a level of indirection where the graph had to call back into
AudioContext. It also removes a dependency on the graph from GraphDriver, where
it can now just resolve a MozPromiseHolder instead.
Differential Revision: https://phabricator.services.mozilla.com/D56075
--HG--
extra : moz-landing-system : lando
This removes some driver-graph interdependencies.
It also changes the logic of EnsureNextIteration() so that it no longer blindly
wakes the driver up, should it be sleeping. Instead it waits until the driver's
next iteration would have occurred anyway, as that seems more expected, and
closer to how an AudioClockDriver works.
Differential Revision: https://phabricator.services.mozilla.com/D56069
--HG--
extra : moz-landing-system : lando
Andreas Pehrson
Cristina Coroiu
Simon Giesecke
Narcis Beleuzu
Csoregi Natalia
Paul Adenot
Karl Tomlinson
Alex Chronopoulos
Sylvestre Ledru
Bogdan Tara