This CL will change the behavior when enabling Delay Agnostic AEC through the media constraint (and AudioOption delay_agnostic_aec)
FROM
Use DA-AEC instead of AECM if there is no HW-AEC
TO
Use DA-AEC even if there is a HW-AEC
Before this change the user will not really know if the Delay Agnostic AEC is running or not, so it is more intuitive if the option overrides the built-in one if the user has asked for it.
BUG=4472
TESTED=locally with a modified AppRTCDemo app
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49859004
Cr-Commit-Position: refs/heads/master@{#9147}
The implementation of this proposal is in progress.
More unittest will be added.
Sender side is being implemented.
Some constants need to be tuned.
BUG=4550
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43299004
Cr-Commit-Position: refs/heads/master@{#9146}
Changes:
1. Documented return values of VoENetwork methods.
2. In VoENetworkImpl: replaced calls to SetLastError() with LOG_F(). SetLastError() is not used anymore because no one is calling LastError() to check for last error. Also, its usage is being removed in Video Engine and we want to be consistent.
3. In VoENetworkImpl: removed WEBRTC_TRACE() usage.
4. In VoENetworkImpl: replaced some defensive code with assert(). We are now assuming that the caller has called VoEBase::Init() where needed. We are also assuming that it is invalid to pass nullptr where data is expected.
5. Updated unit tests accordingly.
R=henrika@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53369004
Cr-Commit-Position: refs/heads/master@{#9145}
When running AEC in extended_filter mode there is no startup phase to evaluate the reported system delay values.
Instead we simply use the first value and scale by two to avoid over compensating when synchronizing render and capture.
We don't need to be too accurate since we have extended the filter length.
On Android we use fixed (measured) reported delay values.
There is no need to be extra conservative here, because that is already built-in in the measured value.
In fact, the difference between devices is large and with such an extra conservative approach the true delay can not be caught by the filter length.
With this change we can improve performance on some devices.
BUG=4472
TESTED=offline on recordings from various devices
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49909004
Cr-Commit-Position: refs/heads/master@{#9144}
The delay estimator has a robust_validation mode used to deliver more stable delay etimates. The cost is increased reaction time when we have a delay jump.
This mode can be turned on and off on the fly, but statistics are not updated while disabled. This makes the estimator unreliable if it is enabled on the fly.
This CL makes sure the update is always done.
BUG=4472
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50889004
Cr-Commit-Position: refs/heads/master@{#9143}
For quick and easy aecdump verifiation storing data as text speeds up the issue tracking process, since anyone can simply view values like mic volume.
BUG=4609
TESTED=verified unpacking an aecdump with flag --txt stores that data in text files
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50849004
Cr-Commit-Position: refs/heads/master@{#9142}
Passed building isac_neon and modules_unittests on Android ARMv7.
Passed modules_unittests with following filters:
--gtest_filter=FiltersTest*
--gtest_filter=LpcMaskingModelTest*
--gtest_filter=TransformTest*
--gtest_filter=FilterBanksTest*
WebRtcIsacfix_CalculateResidualEnergyNeon is removed, refer more in
Issue 4224.
The old review url is at: https://webrtc-codereview.appspot.com/37259004/
BUG=4002
R=andrew@webrtc.org, jridges@masque.com, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48319005
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
Change-Id: I4c16e15930f1b3449d67b67bf023fac28121dff8
Cr-Commit-Position: refs/heads/master@{#9140}
Introduces a new capture class derived from cricket::VideoCapturer that
provides the ability to switch cameras and updates AppRTCDemo to use it.
Some future work pending to clean up AppRTCDemo UI.
BUG=4070
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48279005
Cr-Commit-Position: refs/heads/master@{#9137}
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}
