The VolumeLogger class contains enough logic to deserve its own file.
Also, I want to potentially remove WebRtcAudioManager.java but keep
volume logging. One problem I see with the VolumeLogger is that it
spawns a new thread, and we should try to keep the number of threads
in WebRTC to a minimum. Right now we use excessively many threads.
Bug: webrtc:7452
Change-Id: I4dd8ffb4265903926f0b372715fc6b876fe5d393
Reviewed-on: https://webrtc-review.googlesource.com/65401
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22676}
The class called AudioDeviceModule today is an implementation of a
future interface. We want to reserve the name AudioDeviceModule for
the actual interface. The implementation class has been renamed to
JavaAudioDeviceModule. 'Java' here refers to the fact that the
implementation is using android.media.AudioRecord as input and
android.media.AudioTrack as output, and this is opposed to native
AudioDeviceModule implementations such as OpenSLES and AAudio.
Bug: webrtc:7452
Change-Id: Ifc243c2e169b12a50128ee3252f06d574aa7b358
Reviewed-on: https://webrtc-review.googlesource.com/65400
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22673}
This CL performs some simplifications and cleanups of the moved audio code.
* All JNI interaction now goes from the C++ audio manager calling into
the Java audio manager. The calls back from the Java code to the C++
audio manager are removed (this was related to caching audio parameters).
It's simpler this way because the Java code is now unaware of the C++
layer and it will be easier to make this into a Java interface.
* A bunch of state was removed that was related to caching the audio parameters.
* Some unused functions from audio manager was removed.
* The Java audio manager no longer depends on ContextUtils, and the context has
to be passed in externally instead. This is done because we want to get rid of
ContextUtils eventually.
* The selection of what AudioDeviceModule to create (AAudio, OpenSLES
input/output is now exposed in the interface. The reason is that client should
decide and create what they need explicitly instead of setting blacklists
in static global WebRTC classes. This will be more modular long term.
* Selection of what audio device module to create (OpenSLES combinations) no
longer requires instantiating a C++ AudioManager and is done with static
enumeration methods instead.
Bug: webrtc:7452
Change-Id: Iba29cf7447a1f6063abd9544d7315e10095167c8
Reviewed-on: https://webrtc-review.googlesource.com/63760
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22542}
This CL only affects the forked Android audio device code. The old code
at webrtc/modules/audio_device/android/ is unaffected.
Bug: webrtc:8689, webrtc:8278
Change-Id: I696b8297baba9a0f657ea3df808f57ebf259cb06
Reviewed-on: https://webrtc-review.googlesource.com/36502
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22528}
This CL adds a stand-alone Android AudioDeviceModule in the
sdk/android folder. It's forked from modules/audio_device/android/
and then simplified for the Android case. The stand-alone Android
ADM is available both in the native_api and also under a field trial
in the Java API.
Bug: webrtc:7452
Change-Id: If6e558026bd0ccb52f56d78ac833339a5789d300
Reviewed-on: https://webrtc-review.googlesource.com/60541
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22517}
