This basically gets a grip on the graph while doing driver switches operations
on another thread (system thread or audio thread), because those can take time.
Because the graph is refcounted, it'll be freed when the last operation
finishes, which is what we want.
This patch also only allows driver switching when the graph is in state
LIFECYCLE_RUNNING, which is what we want anyway.
--HG--
extra : rebase_source : 76365981ec909796509bd21e616b1ff8602406bd
As noted in the comment, it is very useful to have this interleaved with the ADB
logcat on Android/b2g, because this way we can correlate gecko state with the
state of the Android HAL.
--HG--
extra : rebase_source : 80df45d0851a06daac3abeab2ea4b5bc7e58a21d
This prevent a bug where the graph would be using a SystemClockDriver even if it
was rendering Web Audio API content.
It went like this:
- An AudioContext was created.
- Some AudioNodeStream (Web Audio API MediaStreams) were created, but their
MediaStreamTrack was not added yet
- During the stream ordering, we would see that we were running an
AudioCallbackDriver (because the MSG was created using an AudioContext, and we
pass in hints regarding the type of MediaStreams that will be added in the
future, to open the audio stream as early as we can, because it can take some
time, the MSG was created directly using an AudioCallbackDriver)
- Also during the stream ordering, we see that none of our MediaStream have an
MediaStreamTrack with an audio track. This triggers a switch to a
SystemClockDriver, because the graph thinks there is no audio.
- During CreateAndDestroyAudioNode, we would not switch to an
AudioCallbackDriver on the first iteration (right after the UpdateStreamOrder
call), because we would be switching, and not during the iteration after,
because we thought we already switched (the first patch makes this more robust).
This basically forces an AudioCallbackDriver if there is an AudioNodeStream,
which prevents unnecessary GraphDriver switches (and save threads creation
destruction, audio stream create and destruction, and all other resources
associated with a GraphDriver).
In the next patches, when the AudioDriver will be implemented, the audio backend
thread (that we don't control), will return from the stack frame where the
nsTArray that allows the MSG thread to exchange message queues in a efficient
manner with the main thread. We put it in the MediaStreamGraph to avoid adding
an allocation/deallocation per iteration on the MSG thread.
In addition, the graph will be able to run on different threads during its
lifetime, so we can't guarantee a stable stack frame to allocate things on
anymore.
The array are renamed with meaningful names, explaining the double-buffering
pattern: the back queue is filled by the main thread, and is swapped with the
front queue that is processed by the MSG thread.
Arrays accesses are synchronized using the driver's monitor.
When "speex/speex_resampler.h" was included, another exported header (in
dist/include) would find the speex/speex_resampler.h in dist/include before
dist/system_wrappers. Visibility of undefined symbols depended on the order
of includes.
This patch changes includes to <speex/speex_resampler.h> so that
WRAP_SYSTEM_INCLUDES works as expected but removes the wrapper when not using
GKMEDIAS_SHARED_LIBRARY.
--HG--
extra : rebase_source : 93ca1dbdd6b489647624326e78539f44c60d0b34
UpdateStreamOrder is not called often because it's expensive (it's called only
when the graph topology changed), and it's earlier in the MSG loop than the
audio stream creation, so we need to tell the newly created AudioStream that a
microphone is active on creation as well.
The panning logic is also now triggered on stream start, because it is async.
This shouldn't be necessary, if clients do the right things, but provides some
safety, in case they don't.
--HG--
extra : rebase_source : e64d663c27f03eff35f538c205cd66d42420d9e4
The stream order is only important if there are connections, in which case
MediaInputPort::Disconnect() calls SetStreamOrderDirty().
MediaStreamGraphImpl::RemoveStream() also calls SetStreamOrderDirty(), which
ensures that mFirstCycleBreaker is updated when necessary.
--HG--
extra : rebase_source : b437f0d078a481725579456d91acc32353e1221a
Also reduce the number of ProcessedMediaStream* static_casts and use a new
variable name |removed| to emphasize what is happening.
--HG--
extra : rebase_source : 50b6c5e2d97a2e4ffbf9db993e1327de8c1d7b36
UpdateStreamOrder is not called often because it's expensive (it's called only
when the graph topology changed), and it's earlier in the MSG loop than the
audio stream creation, so we need to tell the newly created AudioStream that a
microphone is active on creation as well.
The panning logic is also now triggered on stream start, because it is async.
Previously downstream nodes from DelayNodes in cycles sometimes received stale
output from the previous MSG iteration.
Also, if two cycles share a common path, they will now *both* be treated as
cycles, either by muting or by enforcing minimum delay. Previously, marking
one cycle first could prevent detection of other cycles in the same SCC.
--HG--
extra : rebase_source : 82892c538c5ce514165b5f975474df15b99e3d2b
