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
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
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
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
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
This allows to re-use the SharedThreadPool across calls, preventing the need to create a new thread on each call.
MozReview-Commit-ID: CbP6OTYKhHL
--HG--
extra : rebase_source : 969f2c74f00614d6265fe0e25abfb36c9648d564
It is good practice for the MSG to now know the implementation details of the MediaStream.
Additionally, this will allow to make a thread-safe version later.,
MozReview-Commit-ID: CTacCLSeKRP
--HG--
extra : rebase_source : 4feb4beb12f4cd2a6fb67fd6a18f003ea8b18869
mStreams should only ever be accessed on the MSG thread. However, under some shutdown circumstances, it can be accessed on the main thread while the MSG thread is still alive.
This will be corrected in bug 1408276.
MozReview-Commit-ID: 6xWzxxV1Dv3
--HG--
extra : rebase_source : bce92961609da6ea8609ec8ada5a8a30263a84c9
We only access mLifecycleState via a helper which strongly enforced how the member can be accessed.
Two non-safe accesses are corrected.
MozReview-Commit-ID: 6LYk7t4rSyB
--HG--
extra : rebase_source : 9727771e1b04ba1b39f5cf9a6cf94093b7e92b27
They are accessed across multiple threads without the use of monitors.
While it could be argued that some use of the monitor in functions accessing those members would set in place memory barriers, making them atomics remove all doubts as to the thread safetyness of their use.
MozReview-Commit-ID: tyTqeGgDNM
--HG--
extra : rebase_source : 420c38abcfeaa5fca2449034d8e1e3d82949d49d
Describe which members are accessed on the main threads. Other members are only accessed on MSG thread.
MozReview-Commit-ID: CFU4ipRHB1P
--HG--
extra : rebase_source : ad4843da513997a633d2d402384f9478df29c3a7
The reverts to accepting ownership of the monitor regardless of the thread, as
accepted prior to
https://hg.mozilla.org/mozilla-central/rev/e3f39de40209#l1.25
As indicated in the SetCurrentDriver() documentation, it can be called on the
main thread during Revive() before another graph thread is started.
At that point mLifecycleState = LIFECYCLE_RUNNING, and so it is not easy to
adjust AssertOnGraphThreadOrNotRunning() to accept this situation without
making it much more liberal.
An alternative would be to change the Revive() methods to set mDriver
directly, but that would differ from the usual driver-switching pattern.
MozReview-Commit-ID: 9O5qakPVML9
--HG--
extra : rebase_source : 82115938ccd164863ddf6f983e7900705844d0ed
Owning the monitor is not sufficient for consistent state if state can be
accessed without the monitor.
The requirements for SetCurrentDriver() are tighted to require both the
monitor and correct thread, as CurrentDriver() can be called either with the
monitor or on the graph thread.
MozReview-Commit-ID: 90q7Pfa8jxn
--HG--
extra : rebase_source : 6cbcc334dc2bd355d2e9afdebda45a9624edda4b
In this patch, we first deal with the case of MediaElement. Now we replace |PlayVideo| with |VideoFrameContainer::SetCurrentFrames| in |SourceMediaStream::AppendToTrack|. The MSG use TimeStamp::Now() for the TimeStamp of each video frame in most of case except MediaElement case. Becasue the MediaElement has its own VideoQueue, we need to calucalte the correct Timestamp based on the StartTimeStamp of this MediaStream and the elpased time of the video frame in DecodedStream.
MozReview-Commit-ID: 2bm2AHkFXHu
--HG--
extra : transplant_source : %3D%AA%00%CE%A3SV5%8F%84%96%AC%E2%D9%10%EC%85%07N%DF