Summary: We can probably abstract more stuff in the future, but this seems like a good start.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1396907
Differential Revision: https://phabricator.services.mozilla.com/D323
This brings in a lot of noise and makes the test fail.
MozReview-Commit-ID: 70EGM1q1J24
--HG--
extra : rebase_source : f19c191747f2e63303406a43a79454e4ea1ed428
extra : histedit_source : f27d34204de924ab30b5718b240ac3d23677991c
This also is long, but simple.
First, we switch to floats everywhere. This allows to work with any rate, is
more flexible with channel layout, and is a stable API (see audio_processing.h
in webrtc.org).
Then, 10ms worth of audio (already at the graph rate) are poped from the
lock-free queue (fed on the other end by the MSG mixer), and does the following:
- Down mixing to stereo (if needed)
- De-interleaving into planar buffer
- Prepare input and output config
- Actually make the API call
- Free the data
Now, first, we should use a ring buffer, and not have to free any data. Then we
also should not use a lock-free queue, and synchronously process the
reverse-stream, but this is enough code already.
Then, the actual mic data processing:
- Pop a packet from the packetizer (that gives us 10ms worth of audio, note that
we switch from int16_t to float, i.e. we don't do this conversion anymore).
- We convert to planar buffers, deinterleaving
- Prepare input and output config
- Allocate a SharedBuffer of the right size
- Process the data with the processing algorithm selected in UpdateSingleSource
- Append to the a MediaSegment, and append to the right MediaStreamTrack for the
correct SourceMediaStream (the data is already planar and all well).
MozReview-Commit-ID: 2IjgHP0GAmw
--HG--
extra : rebase_source : d2245037e8ee7145af7eef528dcee50817b69d83
extra : histedit_source : 79443c35b82d3bc8833d140dd5afc882b85b4c12
This part is about setting on/off audio processing feature. It's long, but
it's mostly mechanichal changes, from the old API to the new one.
This also covers reseting the processing in case of device changes (with
macros).
MozReview-Commit-ID: EI2TxHRicEr
--HG--
extra : rebase_source : 7044c2d1695cdf0d6a69b4faa19349e3261ef204
extra : histedit_source : f5ac61e7b90ab4d5280623095c443529fb36cde5%2C5c969f1833bdc425842f945a5a8a4702ca13cd56
This needs the next patches to build fine, but is split out for the review.
A side effect of this patch is to break non-duplex, making the whole
init/cleanup phase much simpler.
MozReview-Commit-ID: Caqc8v7CWwZ
--HG--
extra : rebase_source : 6e7d501ef99f3ea5d755a610238b8f260194bba0
extra : histedit_source : 298c7e95a2bd40e8f9ce014e06faad159fca513e
This is "just" for testing, but is cleaner, and skips some resampling, and is in
line with the other patches, to converge with always using MSG rate when we can.
MozReview-Commit-ID: CBQHEDQWJE3
--HG--
extra : rebase_source : a65c4df357a6f56306b63b92416697f01699358f
extra : histedit_source : ae589d7cf7bc3895a0f4b5b496b60846bddf7d1a
This change is the same as bug 1422995. With the conformant Promise handling
and performing micro task checkpoint in Animation tick, waitForFrame() inside
the callback for Animation.ready does not make sure that the next frame happens.
MozReview-Commit-ID: KEz4xmHpGlk
--HG--
extra : rebase_source : 6285f2f3df3d5cb617579bb4f449832ff155e34d
We clamp animation start time on the second restyling when the initial paint
for the animation took over vsync refresh rate (16.6ms normally as of today).
The clamping leads the animation progress to the same value as the initial one.
Once this clamping happens, the animation value does not change even after
waiting for Animation.ready and a reqeustAnimationFrame. To make the animation
value change happen we should wait for one more requestAnimationFrame.
MozReview-Commit-ID: 8OTC0xkKBrr
--HG--
extra : rebase_source : 4c0313f3a96ffc85306f5687630abc13d88aed61
This class contains a bunch of Gecko DOM specific stuff, and it would make
keeping the copy of MediaDecoder in Servo up to date easier if the Gecko
DOM stuff wasn't in MediaDecoder (and the other classes we import).
MozReview-Commit-ID: 3dP1nrQ7sT3
--HG--
extra : rebase_source : 79040a8d3cff6ac946b20a99d68e57630ec60848