This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
(This was previously committed (9e1a6d7c) but had to be reverted
(cbf09274) because Chromium on Android wasn't quite ready for it).
TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47109004
Cr-Commit-Position: refs/heads/master@{#9132}
This is the second try at this. The previous try (a8e285d1) had to be
reverted (bd67f66e) because Chromium still declared a dependency on
move.h.
TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48319004
Cr-Commit-Position: refs/heads/master@{#9123}
This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44269004
Cr-Commit-Position: refs/heads/master@{#9121}
Removes FixedSizeLockFreeQueue which isn't used anymore. This enabled
moving rtc::AtomicOps to webrtc/base/atomicops.h where they should be.
BUG=4330
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51789004
Cr-Commit-Position: refs/heads/master@{#9120}
Instead a ViECapturer object is allocated and directly operated on. This
additionally exposes ViESharedData to Call to access the module
ProcessThread, moving towards Call ownership of shared resources.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45339004
Cr-Commit-Position: refs/heads/master@{#9119}
Changes:
1. Added MockTransport.
2. Added VoiceEngineFixture class to be used in VoE unit tests. This class is in no way final as it is - it will grow as we add more unit tests and our understanding of the Voice Engine grows.
3. Modified VoEBase unit test to use VoiceEngineFixture.
4. Added VoENetwork unit test.
R=henrika@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49759004
Cr-Commit-Position: refs/heads/master@{#9118}
In AEC a fixed fft size is used, but processing can in the lower band be in either 8 or 16 kHz.
Therefore we need a multiplier/rate factor to, for example, map frequency bands in Hz to frequency bins.
The multiplier/rate factor can only be either 1 or 2, but when 48 kHz support was added it was assigned 3.
BUG=crbug.com/482424
R=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43329004
Cr-Commit-Position: refs/heads/master@{#9117}
https://codereview.chromium.org/1051343002 adds a dependency
on Chromium's third_party/junit into base/ which affects our
Android tests that uses that code.
The precompiled JUnit 4.11 JAR file that is only by the
libjingle_peerconnection_java_unittest target on Linux has been
moved to third_party/junit-jar, since it collided with the expected
path for the JUnit dependency mentioned above.
It had to be kept since the Chromium JUnit is only possible to build
when OS==android.
This CL also brings in Mockito and Robolectric, which should be
useful for our Android tests.
Other relevant changes:
* src/buildtools: 3b302fe..15308f4
* src/third_party/libjpeg_turbo: 034e9a9..9e9058b
* src/third_party/libyuv: 32ad6e0..01db3d1
Details: a12e1e1..0cb2549/DEPS
Clang version was not updated in this roll.
BUG=4499
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48239004
Cr-Commit-Position: refs/heads/master@{#9113}
Replaces interface usage with direct calls on ViEEncoder removing a
layer of indirection. Also removing some methods from ViEImageProcess
that were only added for Video{Send,Receive}Stream usage.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45319004
Cr-Commit-Position: refs/heads/master@{#9111}
The trybots ended up in a state that could not be cleaned up
when other tryjobs were altering the checkout with different
variations of dependencies.
TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46139004
Cr-Commit-Position: refs/heads/master@{#9110}
Alson includes
- a test verifying that the option is set
- changed the test verifying delay_agnostic_aec option is set to use non-default value
BUG=4555
TESTED=locally through AppRTCDemo on N7 and Android One
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46059004
Cr-Commit-Position: refs/heads/master@{#9109}
This pattern (read-only base, writable subclass) was picked to maintain a *Buffer option that doesn't copy the source bits when parsing. ByteBuffer and Buffer both copy. I'm open to discussion on what the type relationship would be, though :)
Tests have been added to ensure the symmetric nature of read/write operations.
BUG=
R=bcornell@google.com, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45259005
Cr-Commit-Position: refs/heads/master@{#9107}
Recently, we've hit a rare case of a dependency being
present only below 'unix' and not in the 'android' section
of the DEPS file in Chromium (src/third_party/junit/src).
This exposed a bug in our sync_chromium.py script, which is that
when the --deps flag is passed to gclient sync, _only_ that platform
is processed. That means our Android builders synced with --deps=android
and thus only getting the Android deps, not the 'unix' ones (Linux).
That behavior is different from a regular gclient sync, where both
the current platform's DEPS and the one specified by appending a target_os
variable into .gclient is used.
Ensuring that we pass both the current platform and the optionally specified
DEPS platform into our sync_chromium.py sync, gives us the same behavior
as a regular sync for the special Chromium sync we use.
TESTED=
First:
rm chromium/.last_sync_chromium
Then I ran without this patch and with target_os = ["android"] in .gclient. Verified
that --deps=android was passed.
With this patch, I repeated the above and verified --deps=unix,android was passed.
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52379004
Cr-Commit-Position: refs/heads/master@{#9103}
Add a propagation delay to tests and make the run-time configurable for the fairness tests.
Handle losses in-between feedback messages.
BUG=4549
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49819004
Cr-Commit-Position: refs/heads/master@{#9099}
The way SetExtraOptions() is used today only applies for any one configuration change. The correct way is to set it after all flags have been scanned.
The prefered way to solve this is to use gflags and scan once, followed by applying the configuration when creating audio_processing. This is what is done in the new test tool audioproc_float.cc, but there are still some things left to do before we can replace this one.
BUG=N/A
TESTED=locally
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45279004
Cr-Commit-Position: refs/heads/master@{#9097}
ViECapturer::OnIncomingCapturedFrame can abort if two frames without a
timestamp are delivered at the same time (the same NTP timestamp is
generated). This currently causes captured_frame_ to be in a state
where timestamps (NTP time etc.) are set, but RTP timestamp is not. This
is an issue if the previous frame in captured_frame_ has yet to be
picked up by the capturer thread, as it will pick up captured_frame_ in
a state where the RTP timestamp has not been set.
BUG=chromium:480953
R=magjed@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45299004
Cr-Commit-Position: refs/heads/master@{#9094}
Passed building isac_neon and modules_unittests on Android ARM64 and
ARMv7.
Passed modules_unittests with following filters:
--gtest_filter=FiltersTest*
--gtest_filter=LpcMaskingModelTest*
--gtest_filter=TransformTest*
--gtest_filter=FilterBanksTest*
WebRtcIsacfix_CalculateResidualEnergyNeon is not enabled due to Issue
4224.
BUG=4002
R=andrew@webrtc.org, jridges@masque.com, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44229004
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
Cr-Commit-Position: refs/heads/master@{#9092}
The implementation is a FIR filter bank with DCT modulation, similar to the proposed in "Multirate Signal Processing for Communication Systems" by Fredric J Harris.
The lowpass filter prototype has these characteristics:
* Passband ripple = 0.3dB
* Passband frequency = 0.147 (7kHz at 48kHz)
* Stopband attenuation = 40dB
* Stopband frequency = 0.192 (9.2kHz at 48kHz)
* Delay = 24 samples (500us at 48kHz)
* Linear phase
This filter bank does not satisfy perfect reconstruction. The SNR after analysis and synthesis (with no processing in between) is approximately 9.5dB depending on the input signal after compensating for the delay.
The performance on my workstation of AudioProcessing (with AGC and NS enabled) on a 413s recording compared to previous versions is as follows:
* Input signal has 32kHz sample rate: 3.01s
* Resampling 48kHz to 32kHz: 3.56s
* Today's temporary filter bank: 5.67s
* This filter-bank: 4.62s
BUG=webrtc:3146
R=andrew@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48999005
Cr-Commit-Position: refs/heads/master@{#9090}
This class is being used from both libjingle and webrtc but we recently had a regression when we added dependency on libjingle's Thread class. This cleans that up and moves the implementation of CriticalSection and helper classes into the source file.
I'm also improving debugging facilities and constness.
BUG=
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51769004
Cr-Commit-Position: refs/heads/master@{#9089}
This makes the build more flexible when linking against
prebuilt external libraries.
Use existing build_* variables for libyuv and json in talk/
(already in use in webrtc/).
Also make it possible to avoid building the GTK parts of the Linux build.
BUG=4242
R=andrew@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44179005
Cr-Commit-Position: refs/heads/master@{#9087}
