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
The MSG provides the reverse stream, and feed it directly to the APM.
MozReview-Commit-ID: A6DO407CJkp
--HG--
extra : rebase_source : 65515c02928ed56d57ddd2facd586125df7f09ec
extra : histedit_source : fc61533566deca6023cb749acda96b5772661ebc
This forces us to do a copy. It's not the end of the world but could be avoided.
The number of channels received is now explicit (via
`AudioFrame::num_channels_`), instead of being guessed based on the number of
samples (considering we're always dealing with 10ms of audio, and we know the
rate).
It's still coupled a bit with audio devices, but we cheat, and use a "fake audio
device", which isn't going to touch actual OS APIs.
MozReview-Commit-ID: 1Tfajkv1HQR
--HG--
extra : rebase_source : f9ed6f1beeb3745dc17c4e6264808d1918e8906c
extra : histedit_source : 4338aea961b861462caa79afab66ebaea06e40b2
We used to fix the rate, arbitrarily, to 32kHz. Because the graph is almost
never running at 32kHz (more like 44.1kHz or 48kHz), and the codec would often
not be at 32kHz, this meant multiple resampling:
- Once here, in MediaPipeline, to bring to 32kHz
- Once when getting inserted in the MSG (so that the audio was brought back to
MSG rate)
- Maybe once in cubeb (depending on the platform)
This always removes the second resampling: the track is now at the correct rate,
as far as the MSG is concerned.
Additionally, if the MSG is running at 48kHz, more resampling are saved, because
it's one of the native webrtc.org rates.
MozReview-Commit-ID: DBWcwuWxUpu
--HG--
extra : rebase_source : 588d188f63237f1ce2cb0f2b290d54797d2d22e8
extra : histedit_source : 51733a22f6019140f7a309038a2ff524fbb564a4
Previously, in the parent process, we were treating positive child ids as remote unique ids.
This of course failed when searching remote documents and returned early.
Make sure we only treat ids as remote if they are less than 0.
Ids above 0 are child indices and are handled later in the code for both local and remote children.
MozReview-Commit-ID: 2KmFj6rTXTV
--HG--
extra : rebase_source : 273496a3f6420d184f71795095937638e1e3e2ca
Jonathan Watt
Paul Adenot
Jan de Mooij
Dragana Damjanovic
Marco Castelluccio
Mats Palmgren
Johann Hofmann
Ekanan Ketunuti
Tiberius Oros
Gurzau Raul
Lee Salzman
L10n Bumper Bot
Ben Kelly
James Teh
Valentin Gosu
shindli
Cosmin Sabou
ffxbld