Reason for revert:
Skipping the build of the target "//webrtc/modules/audio_device:audio_device_java" when building webrtc with chromium.
This was causing a failure because in that case it is not possible to refer to the script used by the template "android_shared_srcjar" with an absolute path (which seems to be necessary since the script attribute of action is relative to the invocation target and not to the template declaration).
Original issue's description:
> Revert of Fixing package-boundary violation with srjar_deps (patchset #5 id:80001 of https://codereview.webrtc.org/2610823002/ )
>
> Reason for revert:
> This CL is breaking a chromium.webrtc.fyi: https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Builder/builds/226
>
> I am trying to reproduce the issue on my local machine and I will try to re-land the CL later.
>
> Original issue's description:
> > Fixing package-boundary violation with srjar_deps
> >
> > Without the usage of the srcjar_deps attribute we were not able to
> > include .java files from other packages without violating the package
> > boundary contraint.
> >
> > As an example, in this CL the target "libjingle_peerconnection_java" was
> > directly including .java files from another packages in its "java_files"
> > attribute.
> >
> > Using srcjar_deps we are able to declare the dependency of the target
> > avoiding to create hidden dependencies in the codebase.
> >
> > This is not fixing the webrtc:6356 bug directly but it is a first step to
> > include ThreadUtils classes in libjingle_peerconnection_client_java.jar
> > again.
> >
> > It seems also to be related to the chromium:648244 bug. This can be solved
> > if we can find a way to perform srcjar generation in the android_library
> > target without changing the semantic of the target.
> >
> > BUG=webrtc:6356
> >
> > Review-Url: https://codereview.webrtc.org/2610823002
> > Cr-Commit-Position: refs/heads/master@{#15914}
> > Committed: 10a76592a7
>
> TBR=kjellander@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6356
>
> Review-Url: https://codereview.webrtc.org/2617533005
> Cr-Commit-Position: refs/heads/master@{#15915}
> Committed: eb731ed09eTBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2612953004
Cr-Commit-Position: refs/heads/master@{#15958}
Reason for revert:
This CL is breaking a chromium.webrtc.fyi: https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Builder/builds/226
I am trying to reproduce the issue on my local machine and I will try to re-land the CL later.
Original issue's description:
> Fixing package-boundary violation with srjar_deps
>
> Without the usage of the srcjar_deps attribute we were not able to
> include .java files from other packages without violating the package
> boundary contraint.
>
> As an example, in this CL the target "libjingle_peerconnection_java" was
> directly including .java files from another packages in its "java_files"
> attribute.
>
> Using srcjar_deps we are able to declare the dependency of the target
> avoiding to create hidden dependencies in the codebase.
>
> This is not fixing the webrtc:6356 bug directly but it is a first step to
> include ThreadUtils classes in libjingle_peerconnection_client_java.jar
> again.
>
> It seems also to be related to the chromium:648244 bug. This can be solved
> if we can find a way to perform srcjar generation in the android_library
> target without changing the semantic of the target.
>
> BUG=webrtc:6356
>
> Review-Url: https://codereview.webrtc.org/2610823002
> Cr-Commit-Position: refs/heads/master@{#15914}
> Committed: 10a76592a7TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2617533005
Cr-Commit-Position: refs/heads/master@{#15915}
Without the usage of the srcjar_deps attribute we were not able to
include .java files from other packages without violating the package
boundary contraint.
As an example, in this CL the target "libjingle_peerconnection_java" was
directly including .java files from another packages in its "java_files"
attribute.
Using srcjar_deps we are able to declare the dependency of the target
avoiding to create hidden dependencies in the codebase.
This is not fixing the webrtc:6356 bug directly but it is a first step to
include ThreadUtils classes in libjingle_peerconnection_client_java.jar
again.
It seems also to be related to the chromium:648244 bug. This can be solved
if we can find a way to perform srcjar generation in the android_library
target without changing the semantic of the target.
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2610823002
Cr-Commit-Position: refs/heads/master@{#15914}
The Bazel build format doesn't support having separate
lists of compilation flags for C and C++; it just has a single
copts list for cc_library:
https://bazel.build/versions/master/docs/be/c-cpp.html#cc_binary.copts
This makes it hard to convert our GN targets to Bazel when there are
compiler warnings that aren't supported for C (like -Woverloaded-virtual
being added in bugs.webrtc.org/6653).
The solution for this is to move all .c files to their own targets
and remove C++-only compiler flags during conversion.
New targets:
//webrtc/common_audio:common_audio_c
//webrtc/common_audio:common_audio_neon_c
//webrtc/modules/audio_coding:g711_c
//webrtc/modules/audio_coding:g722_c
//webrtc/modules/audio_coding:ilbc_c
//webrtc/modules/audio_coding:isac_c
//webrtc/modules/audio_coding:isac_fix_c
//webrtc/modules/audio_coding:isac_test_util
//webrtc/modules/audio_coding:pcm16b_c
//webrtc/modules/audio_coding:webrtc_opusj_c
//webrtc/modules/audio_device:mac_portaudio
//webrtc/modules/audio_procssing:audio_processing_c
//webrtc/modules/audio_procssing:audio_processing_neon_c
This CL also adds a PRESUBMIT.py check that will throw an error
if targets are mixing .c and .cc files, to preven this from regressing.
BUG=webrtc:6653
NOTRY=True
Review-Url: https://codereview.webrtc.org/2550563003
Cr-Commit-Position: refs/heads/master@{#15433}
There's no longer any need to make the two arguments have the same
signedness, so we can remove a bunch of superfluous (and sometimes
dangerous) casts.
It turned out I also had to fix the safe_cmp functions to properly handle
enums that are implicitly convertible to integers.
NOPRESUBMIT=true
BUG=webrtc:6645
Review-Url: https://codereview.webrtc.org/2534683002
Cr-Commit-Position: refs/heads/master@{#15281}
There's no longer any need to make the two arguments have the same
signedness, so we can drop the "u" suffix on literal integer
arguments.
NOPRESUBMIT=true
BUG=webrtc:6645
Review-Url: https://codereview.webrtc.org/2535593002
Cr-Commit-Position: refs/heads/master@{#15280}
- Out from modules/utility/ and into modules/audio_device/ios/ - there they are used.
BUG=none
Review-Url: https://codereview.webrtc.org/2526273002
Cr-Commit-Position: refs/heads/master@{#15236}
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/2525943003
Cr-Commit-Position: refs/heads/master@{#15223}
Due to bugs.webrtc.org/216 code that includes
//webrtc/modules/audio_device:mock_audio_device fails to compile on
Windows unless a warning flag is switched off. It seems that
googlemock changes types of overridden virtual method parameters from
'const int' to 'int', which causes the VS compiler to report an error.
The problem was not solved by suppressing the flag wd4373 in
//webrtc/modules/audio_device:mock_audio_device, because targets that
include the headers are compiled separately.
This CL adds the flag suppression to the GN variable
|all_dependent_configs|. Then GN will apply the configuration to all
reachable dependencies. This is needed to reduce clutter and extra
conditions in dependency build targets.
The reason for |all_dependent_configs| before |public_configs| is
for a situation in which a targets headers include the headers from
this target. Then dependencies of dependencies will have a copy of
this targets' code after preprocessing, and compilation will fail.
This will happen if we e.g. change mock_voice_engine to return a
MockAudioTransport or MockAudioDevice.
This change has been tested by compiling a dependent CL
(https://codereview.webrtc.org/2454373002/) which uses these mocks
on Windows without suppressing the flag.
There is no GYP change, because test code has been removed from GYP.
NOTRY=True
BUG=webrtc:216
Review-Url: https://codereview.webrtc.org/2492713003
Cr-Commit-Position: refs/heads/master@{#15024}
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}
- Removes the lock that was used to protect the audio transport object.
It is now protected "by design" instead.
- Removes rec/play_bytes_per_sample_ since we only support 16-bit samples.
BUG=webrtc:6560
R=kwiberg@webrtc.org
Review URL: https://codereview.webrtc.org/2466613002 .
Cr-Commit-Position: refs/heads/master@{#14950}
Contains fixes for a non-perfect implementation in https://codereview.webrtc.org/2328433003/
Summary:
Adds WebRTC.Audio.RecordedOnlyZeros UMA stat when recording stops if:
- All level estimates during the audio session were zero, and
- If the audio session was longer than 10 seconds.
Adds four simple methods to the AudioDeviceBuffer (ADB) class to allow the ADM
to update the ADB about when media starts and stops in both directions.
Moves any "critical" parst out frome the timer (based on task queue) and ensures
that it only does trivial logging tasks.
The task queue is now owned by a unique pointer to improve control of when it
starts and stops.
Adds time measurements (for logging) of both total time playing out and total
recording time. Units are in milliseconds.
BUG=webrtc:6592
Review-Url: https://codereview.webrtc.org/2445363003
Cr-Commit-Position: refs/heads/master@{#14854}
Now does level estimate on the audio threads to avoid complex
copying of audio data to task queue. The old implementation could
also crash due to unclear ownership of the audio buffer.
BUG=webrtc:6569
R=kwiberg@webrtc.org
Review URL: https://codereview.webrtc.org/2433393002 .
Cr-Commit-Position: refs/heads/master@{#14720}
The main goal of this CL is to remove old buffer handling using static arrays
and switch to the improved rtc::Buffer class instead.
By doing so, we can remove some members (since Buffer maintains them instead) and
do some additional cleanup.
This CL also fixes some minor style issues and improves the locking mechanism.
Finally, AudioDeviceBuffer::SetRecordingChannel() is deprecated since it has never been
used and is not included in any test.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2333273002
Cr-Commit-Position: refs/heads/master@{#14661}
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}
