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
With block size 128, rounding `128` to end of next block gives `256`, which is
not what we want when running MSG iterations. That could mean over-iterating and
buffering unnecessary amounts of silence.
MozReview-Commit-ID: vW14l2ygRy
--HG--
extra : rebase_source : 8aeedc8958e646f9730c9163447e3355a73fd42e
I hit this during local tests. It's a fine invariant but it doesn't hold in
forced shutdown.
MozReview-Commit-ID: HtoiGwf7IMI
--HG--
extra : rebase_source : 707de2fe08ccad99a06dab00969e2f140e63abad
With the added invariant that NotifyPull() needs a MediaStreamListener present
to not underrun, we need SetPullEnabled() and AddListener() to stay in sync by
using the same signaling mechanism.
MozReview-Commit-ID: 49KWdiTOG98
--HG--
extra : rebase_source : d0ad44d7ce431aa792c4908f96baf0c0920dbe90
There are legit cases when a SourceMediaStream gets pulled without a listener
present.
A clear example (though a corner case and easily overlooked) that I've hit is
when the last track is ended and the only stream listener is removed at the same
time. This leads to a pull on the next iteration where the track-end has not
yet been picked up. And thus, a false positive error saying that a live track
doesn't have listeners.
The real error here will now instead be caught by the new assert for when a
pulled stream underruns (which is now illegal).
MozReview-Commit-ID: 3e8FcCZfhYJ
--HG--
extra : rebase_source : ada823dbab07c8ca50429cd854b0c4b1df688fbb
Instead allocate it on the stack and provide it as out parameter.
MozReview-Commit-ID: 9fSJ68EfAga
--HG--
extra : rebase_source : 81430b45e4341d0f4208097f021c2a917e8e2645