There are currently two nearly identical classes called
MockAudioTransport defined in two unit tests:
android/audio_transport_unittest.cc and
/ios/audio_transport_unittest_ios.cc
This change defines a common mocked AudioTransport. The two current
mocks are rewritten to use the common one. A GN target is created for
this mock and MockAudioDevice.
This change will allow to provide a mocked AudioTransport to
AudioState in a dependent CL https://codereview.webrtc.org/2454373002/
BUG=webrtc:6346
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2493483002
Cr-Commit-Position: refs/heads/master@{#15010}
Reason for revert:
There is a risk of ending up in a bad state due to race conditions with this patch. Tests in downstream clients have shown that it can
happen that an output stream is opened up in MUSIC mode when it should not.
Reverting since the new functionality added here is not worth the
risk of breaking existing clients.
Original issue's description:
> Android audio playout now supports non-call media streams.
>
> The default (preferred) stream type for output audio is STREAM_VOICE_CALL since the WebRTC stack is mainly intended for VoIP calls. But if the user wants to run in another mode than COMM mode, we now accept it and change the stream type to STREAM_MUSIC instead. It can e.g. be suitable for applications that does not record audio or if a call shall be casted to a Chromecast device.
>
> The solution is somewhat experimental.
>
> NOTRY=TRUE
>
> BUG=webrtc:4767
>
> Committed: https://crrev.com/872f614111f436d15e29516ce19c3b63d25b8639
> Cr-Commit-Position: refs/heads/master@{#14613}
TBR=henrik.lundin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4767
Review-Url: https://codereview.webrtc.org/2420583002
Cr-Commit-Position: refs/heads/master@{#14626}
The default (preferred) stream type for output audio is STREAM_VOICE_CALL since the WebRTC stack is mainly intended for VoIP calls. But if the user wants to run in another mode than COMM mode, we now accept it and change the stream type to STREAM_MUSIC instead. It can e.g. be suitable for applications that does not record audio or if a call shall be casted to a Chromecast device.
The solution is somewhat experimental.
NOTRY=TRUE
BUG=webrtc:4767
Review-Url: https://codereview.webrtc.org/2411263003
Cr-Commit-Position: refs/heads/master@{#14613}
Compromise solution where WebRtcAudioUtils.setWebRtcBasedAutomaticGainControl() is marked
as deprecated and where as many APIs as possible that touches the HW AGC are removed. Some basic architecture is saved to ensure that we can restore usage of
the HW AGC if ever required for future devices.
The AppRTCMobile demo does still contain an AGC check box but it is now grayed out.
BUG=b/30387905
Review-Url: https://codereview.webrtc.org/2402883003
Cr-Commit-Position: refs/heads/master@{#14596}
RunPlayoutAndRecordingInFullDuplex fails sometimes on Android swarming
bots, presumably because the timing is hardware dependent.
This test ensures that audio starts pumping. The exact performance is
not that important.
R=kjellander@webrtc.org, henrika@webrtc.org
BUG=webrtc:6464
NOTRY=True
Review-Url: https://codereview.webrtc.org/2391563002
Cr-Commit-Position: refs/heads/master@{#14492}
The former is always defined (by webrtc/base/checks.h) to either 0 or
1, whereas the latter isn't necessarily defined.
NOTRY=true
BUG=webrtc:6451
Review-Url: https://codereview.webrtc.org/2384693002
Cr-Commit-Position: refs/heads/master@{#14474}
NOTE: the new code is disabled by default in the WebRtcAudioManager to ensure that
OpenSL ES is not accidentally activated in existing clients. There are still some
unresolved issues to sort out before it can be utilized.
Enables possibility to use OpenSL ES based audio in both directions for WebRTC.
All unit tests and demo clients have been tested with the new implementation but
the new support is behind a flag (see above).
More testing is needed before it can be used in the field and additional support for
hardware effects is still missing.
BUG=webrtc:5925
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2119633004 .
Cr-Commit-Position: refs/heads/master@{#14290}
Trivial patch which avoids logs that are of no value.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2250403002
Cr-Commit-Position: refs/heads/master@{#13799}
When playing out, for example, you'd see 3 lines for every call to
PlayoutDelay, which happens quite often (every sample?).
The ones around the Playout/Recording Warning/Error are only once a
second, but they don't seem to add anything. Same with
Process/TimeUntilNextProcess, which just log that the method is called.
BUG=
Review-Url: https://codereview.webrtc.org/2202243004
Cr-Commit-Position: refs/heads/master@{#13763}
when building with default warnings.
This is in preparation for making a gn target for audio_device_tests.
BUG=webrtc:6170, webrtc:163
NOTRY=True
Review-Url: https://codereview.webrtc.org/2219653004
Cr-Commit-Position: refs/heads/master@{#13759}
The goal of this change is to log the volume level for the
current audio stream so we can keep track of what volume the
user selects during a call.
BUG=b/30376577
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/2182043005 .
Cr-Commit-Position: refs/heads/master@{#13555}
This CL eliminates repeated calls to AudioEffect.queryEffects() on Android when configuring the audio device. Each of these calls was taking 5-10 milliseconds on the devices I was testing (Nexus 4, Nexus 5), and setting up the audio device involved around 10 of these calls.
This change adds a method that checks the cached list of effects before calling the underlying operating system API; this eliminated about half of these calls. The other half happened inside static methods such as NoiseSuppressor.isAvailable(), which are just convenience wrappers for searching through the list of effects. These calls have been replaced with searching through the cached list of effects, reducing the time to configure audio processing effects from 60-80 ms to 5-10. This results in a similar improvement in call setup time.
BUG=
Review-Url: https://codereview.webrtc.org/2051323002
Cr-Commit-Position: refs/heads/master@{#13115}
A new API is added which enables detection of support of pro-audio on
Android. This is part of a larger change and the new API is not used yet.
Most likely it will only be used for logging purposes.
BUG=webrtc:5925
Review-Url: https://codereview.webrtc.org/2015483002
Cr-Commit-Position: refs/heads/master@{#12890}
ADMs were previously created by CreateAudioDeviceModule which was
removed in previous refactoring without a replacement added.
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1944883002 .
Cr-Commit-Position: refs/heads/master@{#12613}
They're just no-ops now, and will soon go away.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1914153002
Cr-Commit-Position: refs/heads/master@{#12510}
We can now use std::move instead!
This CL leaves the Pass methods in place; a follow-up CL will add deprecation annotations to them.
Review URL: https://codereview.webrtc.org/1460043002
Cr-Commit-Position: refs/heads/master@{#11064}
