The MSG provides the reverse stream, and feed it directly to the APM.
MozReview-Commit-ID: A6DO407CJkp
--HG--
extra : rebase_source : df4ad965c171eab5a72a8d09e0305b1e79325a03
extra : source : e92ff1339db1ca5affa56ccdbec1c8b3836bcd95
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 : c0c8c240621b076bb3b056689f45289212498903
extra : source : 9e92591ba6dcb18364da98756c645c91bfe81517
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 : 2b961a8bd91d952ccbe9df5a6ab7649321f282a6
extra : source : a3d9aa2649b95329d0cf686d79aa5179e9f3506d
Nothing significant in this release, just to be in sync with upstream
MozReview-Commit-ID: GOMzG6TOHYg
--HG--
extra : rebase_source : 73c7a83e358d0b8c7686f0b79d805947c928600e
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
* +x on the script
* add the #!/bin/sh
* check the number of args
* readme has been renamed
* todo.txt no longer exits
MozReview-Commit-ID: 67JIO610CNg
--HG--
extra : rebase_source : ee717814cb1f2cd64369caa0c7ee89dedad61c66
Specifically: without this fix, icecc + clang users will hit this clang bug when compiling stdatomics.h:
https://bugs.llvm.org/show_bug.cgi?id=26828
MozReview-Commit-ID: BJUN82HyXpF
--HG--
extra : rebase_source : 3f06d3401198de45240aa9f0c7c865e048f90b89
Specifically: without this fix, icecc + clang users will hit this clang bug when compiling stdatomics.h:
https://bugs.llvm.org/show_bug.cgi?id=26828
MozReview-Commit-ID: BJUN82HyXpF
--HG--
extra : rebase_source : dde23b590c3eebe9fb56dba2d81738059efde654
