BUG=4573,2982,2175,3590
TEST=modules_unittests --gtest_filter=AudioDevice*, AppRTCDemo and WebRTCDemo
Summary:
- Removes dependency of the 'enable_android_opensl' compiler flag.
Instead, OpenSL ES is always supported, and will enabled for devices that
supports low-latency output.
- WebRTC no longer supports OpenSL ES for the input/recording side.
- Removes old code and demos using OpenSL ES for audio input.
- Improves accuracy of total delay estimates (better AEC performance).
- Reduces roundtrip audio latency; especially when OpenSL can be used.
Performance verified on: Nexus 5, 6, 7 and 9. Samsung Galaxy S4 and S6.
Android One device.
R=magjed@webrtc.org, phoglund@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51759004
Cr-Commit-Position: refs/heads/master@{#9208}
Before this change, a decoder was registered into ACMReceiver through
the CodecOwner; the CodecOwner had to have a pointer back to the
AudioCodingModuleImpl object to make this call. With this change, the
AudioCodingModuleImpl object asks the CodecOwner for a decoder pointer
instead, making the chain of calls more straightforward.
COAUTHOR=henrik.lundin@webrtc.org
BUG=4474
R=jmarusic@webrtc.org, minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52439004
Cr-Commit-Position: refs/heads/master@{#9204}
AudioCodingModuleImpl::Add10MsData() calls two private methods that
together do all the work: Add10MsDataInternal() and Encode(). They
each took locks internally in order to protect access to, among other
things, codec_manager_.
This turned out to be inadequate. Add10MsDataInternal() calls
codec_manager_.CurrentEncoder()->SampleRateHz() in order to be able to
resample the audio data to what the current encoder wants. When the
resampled data is fed to the encoder deep inside the Encode() call,
that sample rate must still be correct, but occasionally it wasn't,
which triggered a CHECK. (The specific test that failed was the
voe_auto_test subtest
CodecTest.OpusMaxPlaybackRateCannotBeSetForNonOpus, which changes the
current encoder while encoding is in progress.)
This CL solves the problem by covering all of
AudioCodingModuleImpl::Add10MsData() in a single critical section, so
that the sample rate obtained in Add10MsDataInternal() is guaranteed
to still be valid during the Encode() call.
BUG=4644
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52459004
Cr-Commit-Position: refs/heads/master@{#9174}
A better solution than forcing OPUS_APPLICATION_VOIP when enabling DTX has been found, which is to set OPUS_SIGNAL_VOICE.
This reduces the uncertainty of entering DTX over silence period of audio.
This CL contains the setup of OPUS_SIGNAL_VOICE and decoupling opus application mode with DTX.
BUG=4559
R=henrik.lundin@webrtc.org, henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46959004
Cr-Commit-Position: refs/heads/master@{#9168}
The main purpose of this CL is to clean up RTCPSender::PrepareRTCP, but
it has quite a few ramifications. Notable changes:
* Removed the rtcpPacketTypeFlags bit vector and don't assume
RTCPPacketType values have a single unique bit set. This will allow
making this an enum class once rtcp_receiver has been overhauled.
* Flags are now stored in a map that is a member of the class. This
meant we could remove some bool flags (eg send_remb_) which was
previously masked into rtcpPacketTypeFlags and then masked out again
when testing if a remb packet should be sent.
* Make all build methods, eg. BuildREMB(), have the same signature.
An RtcpContext struct was introduced for this purpose. This allowed
the use of a map from RTCPPacketType to method pointer. Instead of
18 consecutive if-statements, there is now a single loop.
The context class also allowed some simplifications in the build
methods themselves.
* A few minor simplifications and cleanups.
The next step is to gradually replace the builder methods with the
builders from the new RtcpPacket classes.
BUG=2450
R=asapersson@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48329004
Cr-Commit-Position: refs/heads/master@{#9166}
When compiling against an OSX 10.7+ SDK, explicitly redeclare methods only
available from an OSX 10.7+ SDK. This suppresses the clang warning
-Wpartial-availability, which will be turned on in the future.
BUG=chromium:471823
R=jiayl@webrtc.org, mark@chromium.org
Review URL: https://webrtc-codereview.appspot.com/44359004
Cr-Commit-Position: refs/heads/master@{#9163}
This adds functionality from audioproc_float. The geometry parsing code
is now shared from test_utils.h. I removed the "mic_spacing" flag from
audioproc_float because it's a redundancy that I suspect isn't very
useful.
Includes a cleanup of the audio_processing test utils. They're now
packaged in targets, with the protobuf-using ones split out to avoid
requiring users to depend on protobufs.
pcm_utils is no longer needed and removed.
The primary motivation for this CL is that AudioProcessing currently
doesn't support more than two channels and we'd like a way to pass
more channels to the beamformer.
R=aluebs@webrtc.org, mgraczyk@chromium.org
Review URL: https://webrtc-codereview.appspot.com/50899004
Cr-Commit-Position: refs/heads/master@{#9157}
CodecOwner is introduced here; AudioEncoderMutable was introduced in a
previous commit, but had no users until now. The only remaining task
for ACMGenericCodec was to construct and maintain the stack of speech,
CNG, and RED encoders. This task is now handled by the CodecOwner,
which is owned and used by the CodecManager.
COAUTHOR=henrik.lundin@webrtc.org
BUG=4228
R=jmarusic@webrtc.org, minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43189004
Cr-Commit-Position: refs/heads/master@{#9152}
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}
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}
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 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}
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}
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}
