With this change, the graph is already running when mEndTime is set and so
this must be done on the graph thread for consistent ordering with in-flight
messages.
Depends on D10168
Differential Revision: https://phabricator.services.mozilla.com/D10169
--HG--
extra : moz-landing-system : lando
This will prevent rendering from starting when the graph thread is started
before StartNonRealtimeProcessing() is called.
Depends on D10167
Differential Revision: https://phabricator.services.mozilla.com/D10168
--HG--
extra : moz-landing-system : lando
AudioWorket will need to keep processing events on the graph thread.
The graph thread is instead shut down when the AudioContext is destroyed.
Depends on D10165
Differential Revision: https://phabricator.services.mozilla.com/D10166
--HG--
extra : moz-landing-system : lando
It's not maintained and probably does not work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D5438
--HG--
extra : rebase_source : ccd622e40844dda5d16266e49991462d4ea94224
This is slightly slower, especially if the main thread is busy, but it's cleaner
and actually safe.
MozReview-Commit-ID: 4C2FalxmE3L
--HG--
extra : rebase_source : 3f1341397bede31fcc35dab5a0cbf59b893f9b81
For an AudioCallbackDriver, the number of input channels is immutable, and
passed at construction, so that it's less necessary to rely on global state.
MozReview-Commit-ID: F9TL1H92z3W
--HG--
extra : rebase_source : 5193488592ca97273eb2b6f43d4c7a0e4beb0a33
The MSG now can feed microphone data to all its input listeners. This paves the
way for multiple input device, if we feel it's needed at some point, but does
not implement it.
The method for adding/removing inputs are also cleaned up.
MozReview-Commit-ID: 9OX4Da6Gjq2
--HG--
extra : rebase_source : 043c486e53f9220ae61fd788ed86064ba723f1a4
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
These two methods assert for OnGraphThreadOrNotRunning when their callers assert for OnGraphThread. Since the second assert is more limited we do not have to assert for a wider eventuality.
MozReview-Commit-ID: 2cgzO160l6F
--HG--
extra : rebase_source : 922a3d9775bb25022e456c19495b5e1666e7f8b7
That method is used on update of channelCount constraint. By raising a ControlMessage to MediaStreamGraph we avoid the lock the mutex on a non priority thread. Unfortunately we have to send the message in main thread first, thankfully this will change soon.
MozReview-Commit-ID: 8JRSmKGGVAN
--HG--
extra : rebase_source : 3d3a3f03ec601e5fbe0e8fda01608ee8cadf8d78
MediaStream::Destroy() is part of a controlled shutdown sequence.
If there are still tracks with content beyond Destroy() they will
only get caught by the dtor, which may be on CC shutdown and too late.
MozReview-Commit-ID: GV6XRiTCIRk
--HG--
extra : rebase_source : 88b5730c3566f8405c8f6da5e93e7cc446b9dd75
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 03cefb8edf12b077607ae71aeb999fd0ac966674
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : b4310af51efa83c6670ba4e37433f7a23a575bba
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 52d0b6a3b054238c79f1b224d6cbfcbaec743a67
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0