The test is already disabled on iOS < 16 and fails on iOS 16 with this error:
/../../sdk/objc/unittests/RTCCameraVideoCapturerTests.mm:556: error: -[RTCCameraVideoCapturerTestsWithMockedCaptureSession testStartCaptureSetsOutputDimensionsInvalidPixelFormat] : ((width) equal to ([output.videoSettings[(id)kCVPixelBufferWidthKey] intValue])) failed: ("110") is not equal to ("0")
https://chromium-swarm.appspot.com/task?id=5fc0ac239b2dd110
Change-Id: Ia0a5c4290261b204d5e369dfc62113268ef48127
Bug: webrtc:14829, b/264630045
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290895
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39130}
This is required by some virtual cameras, like Snap Camera from
Snapchat.
Bug: webrtc:14783
Change-Id: I3d841936c17f3f227af9a94a4c3b0f37940d43b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288361
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39073}
Keeping the headers to allow compatibility with current users
that expect the headers to be in that target before they are
also updated.
Bug: webrtc:9838
Change-Id: I8b1e88850958e92c043686587a37791f01860220
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290569
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39031}
making it clear what unit is being used.
BUG=webrtc:13756
Change-Id: I6354d35a8e02bb93a905ccf32cb0b294b4813e41
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/289460
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39008}
See commit
https://webrtc.googlesource.com/src/+/c8a6fb2bb8762de17008dee97c5fb6e762f7e056
where the setup methods for RTCCameraVideoCaptureTests' test cases were
lost. Both "setup" where XCTest instead looks for "setUp", and
"setupWithMockedCaptureSession" which isn't called explicitly anywhere.
This commit splits the old RTCCameraVideoCaptureTests into two;
RTCCameraVideoCaptureTests for tests using "setup", and
RTCCameraVideoCaptureTestsWithMockedCaptureSession for tests using
"setupWithMockedCaptureSession".
Bug: webrtc:8382
Change-Id: I64cefff744e12f62d65e04133512de1e10d17d95
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288601
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38931}
removes cached pixelbufferpool and instead retrieves current pool from the compressionSession each time (as recommended by apple docs)
Bug: webrtc:14688
Change-Id: I2244e69e7f32b912021db0905b9d5867d0bf6357
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284240
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38920}
This helps in figuring out which dependencies exist, and gets closer
to obeying the "one target per .cc file" rule.
Test failures seem unrelated, so using No-Try.
No-Try: true
Bug: webrtc:14775
Change-Id: Id25466c8b8fe628d05c819cf7c69ae6d8421c6cf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288020
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38910}
Notifier is thread-hostile, and we have added a SequenceChecker
on https://webrtc-review.googlesource.com/c/src/+/252520 ,
so this comment is no longer needed.
Bug: None
Change-Id: I39f7f75a786dd27d2f6299d85676e7182d9032eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288180
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38899}
This cl/ attempts to fix (rather) rare crashes in
OnNetworkConnected_n by loosening the assumptions
that a network handle will keep it's network name.
With this cl/ it is possible that a NetworkHandle
can call OnNetworkConnected_n with one interface name
and then directly afterwards call it with another (
w/o an OnNetworkDisconnected_n inbetween).
This is the only scenario in which I could see the previous
crash occurring.
i.e
OnNetworkConnected(handle, "some-if-name")
OnNetworkConnected(handle, "some-other-name")
- previously this caused crash,
- now this is treated as if there was an OnNetworkDisconnected(handle) in between.
---
Also 1: shamelessly copy TYPE_MOBILE_DUN & TYPE_MOBILE_HIPRI from chromium: 87987f0e76
Also 2: Modify testcase not to use real interface names, so I can ran them on personal test phone w/o the real networks interfering.
Bug: webrtc:13741
Change-Id: I5480d5ce7031c2b5c09b958064076d02b3db1248
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285980
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38808}
AndroidNetworkMonitor::SetNetworkInfos assumes this method is called
only once, but unittests calls it twice.
One is called by the startMonitoring Java method, and the other is
called by each test.
Because of this, these tests will not succeed if dcheck_always_on is true.
To solve this problem, use OnNetworkConnected_n
instead of SetNetworkInfos in each test.
Bug: None
Change-Id: I027706ad5ccd597a91e3a66f15e181ee22d4aaa9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285861
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#38798}
On Android bindings, do not build a DtmfSender instance in a
RtpSender if its video kind is Video.
This will prevent showing an error when trying to access
that DtmfSender instance that has no native reference
Bug: webrtc:14680
Change-Id: Iba67a12cae8604c032915156b581af269f6ed265
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283742
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38724}
As the synchronous version only posts a task to recreate the encoder
later, it is not possible to catch errors and state changes that
could appear then.
The asynchronous version of SetParameters() aims to solve this by
providing a callback to wait for the completion of the encoder
reconfiguration, allowing any error to be propagate and subsequent
getParameters() call to have up to date information.
Bug: webrtc:11607
Change-Id: I5548e75aa14a97f8d9c0c94df1e72e9cd40887b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38627}
The file was renamed, see
https://groups.google.com/u/1/g/discuss-webrtc/c/ZQiP4f_bpw4
Bug: webrtc:14180
Change-Id: Ia76c85ba7d9da6b3a93d0a67a4b6a5187e07e230
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283084
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38616}
This is a reland of commit 937a59268e
Check if codec requested in createEncoder/Decoder is supported and return null if not.
Original change's description:
> Call native codec factories from Android ones.
>
> Android video codec factories are expected to be synchronised with the native ones in terms on supported codecs. But before this change there were differences:
>
> 1. Native decoder factory keeps AV1 support behind RTC_DAV1D_IN_INTERNAL_DECODER_FACTORY while Android decoder factory advertises AV1 unconditionally;
>
> 2. Native encoder factory advertises AV1 if RTC_USE_LIBAOM_AV1_ENCODER is enabled while Android encoder factory never advertises AV1.
>
> This CL synchronises the codecs set in Android factories with that of native factories by calling native factories from Android ones.
>
> Bug: webrtc:13573, b/257272020
> Change-Id: I99d801eda0c5f3400bac222b9b08d719f1a6ed72
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282240
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38583}
Bug: webrtc:13573, b/257272020
Change-Id: Ida7bb9a2954b836a07ad560de29c1f8088264b77
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282802
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38607}
Android video codec factories are expected to be synchronised with the native ones in terms on supported codecs. But before this change there were differences:
1. Native decoder factory keeps AV1 support behind RTC_DAV1D_IN_INTERNAL_DECODER_FACTORY while Android decoder factory advertises AV1 unconditionally;
2. Native encoder factory advertises AV1 if RTC_USE_LIBAOM_AV1_ENCODER is enabled while Android encoder factory never advertises AV1.
This CL synchronises the codecs set in Android factories with that of native factories by calling native factories from Android ones.
Bug: webrtc:13573, b/257272020
Change-Id: I99d801eda0c5f3400bac222b9b08d719f1a6ed72
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282240
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38583}
It's deprecated and has been removed from Chrome. Let's follow suite.
// Passing all but unrelated bots
NOTRY=True
Bug: webrtc:14608
Change-Id: I6f2601af5b1dc08164230ebf15db2d2f1754f9e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38488}
Currently if you want to obtain the stats for a specific sender/receiver
in Android, you need to call peerConnection.getStats() and filter
manually the result by sender.
pc.getStats(receiver/sender) exists in c++ and ios but was not exposed
in Android
Bug: webrtc:14547
Change-Id: I9954434880f0f93821fcd2e2de24a875e8d136ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275880
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38428}
This is needed in order to use jint and make the header self contained.
Bug: b/251890128
Change-Id: Ie6c323113370a1d49f68c783137292e1c0be07d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278780
Commit-Queue: Xavier Lepaul <xalep@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38351}
This CL adds #includes to header files in order to make them
self contained after the preprocessor pass.
Bug: b/251890128
Change-Id: I81c3ba38fb8ab8a2bbd151ba99aa871fae9f1b1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278422
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38327}
BlockingCall doesn't take rtc::Location parameter and thus most of the dependencies on location can be removed
Bug: webrtc:11318
Change-Id: I91a17e342dd9a9e3e2c8f7fbe267474c98a8d0e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274620
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38045}
Align thread checkers with the class comment,
i.e. ensure AudioDevice is used and destroyed on the same thread it was constructed on, not just the same thread AudioDevice::Init was called.
Bug: webrtc:9702
Change-Id: Ib905978cc8173266151adf26e1b7317f1d3852bc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274164
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38018}
This is a reland of commit 9a0a6a198e
Original change's description:
> Reland "ObjC ADM: record/play implementation via RTCAudioDevice [3/3]"
>
> This is a reland of commit 2b9aaad58f
>
> Original change's description:
> > ObjC ADM: record/play implementation via RTCAudioDevice [3/3]
> >
> > # Overview
> > This CL chain exposes new API from ObjC WebRTC SDK to inject custom
> > means to play and record audio. The goal of CLs is achieved by having
> > additional implementation of `webrtc::AudioDeviceModule`
> > called `ObjCAudioDeviceModule`. The feature
> > of `ObjCAudioDeviceModule` is that it does not directly use any
> > of OS-provided audio APIs like AudioUnit, AVAudioEngine, AudioQueue,
> > AVCaptureSession etc. Instead it delegates communication with specific
> > system audio API to user-injectable audio device instance which
> > implements `RTCAudioDevice` protocol.
> > `RTCAudioDevice` is new API added to ObC WebRTC SDK in the CL chain.
> >
> > # AudioDeviceBuffer
> > `ObjCAudioDeviceModule` does conform to heavy `AudioDeviceModule`
> > interface providing stubs for unrelated methods. It also implements
> > common low-level management of audio device buffer, which glues audio
> > PCM flow to/from WebRTC.
> > `ObjCAudioDeviceModule` owns single `webrtc::AudioDeviceBuffer` which
> > with the help of two `FineAudioBuffer` (one for recording and one for
> > playout) is exchanged audio PCMs with user-provided `RTCAudioDevice`
> > instance.
> > `webrtc::AudioDeviceBuffer` is configured to work with specific audio:
> > it has to know sample rate and channels count of audio being played and
> > recorded. These formats could be different between playout and
> > recording. `ObjCAudioDeviceModule` stores current audio parameters
> > applied to `webrtc::AudioDeviceBuffer` as fields of
> > type `webrtc::AudioParameters`. `RTCAudioDevice` has it's own variable
> > audio parameters like sample rate, channels count and IO buffer
> > duration. The audio parameters of `RTCAudioDevice` must be kept in sync
> > with audio parameters applied to `webrtc::AudioDeviceBuffer`, otherwise
> > audio playout and recording will be corrupted: audio is sent only
> > partially over the wire and/or audio is played with artifacts.
> > `ObjCAudioDeviceModule` reads current `RTCAudioDevice` audio parameters
> > when playout or recording is initialized. Whenever `RTCAudioDevice`
> > audio parameters parameters are changed, there must be a notification to
> > `ObjCAudioDeviceModule` to allow it to reconfigure
> > it's `webrtc::AudioDeviceBuffer`. The notification is performed
> > via `RTCAudioDeviceDelegate` object, which is provided
> > by `ObjCAudioDeviceModule` during initialization of `RTCAudioDevice`.
> >
> > # Threading
> > `ObjCAudioDeviceModule` is stick to same thread between initialization
> > and termination. The only exception is two IO functions invoked by SDK
> > user code presumably from real-time audio IO thread.
> > Implementation of `RTCAudioDevice` may rely on the fact that all the
> > methods of `RTCAudioDevice` are called on the same thread between
> > initialization and termination. `ObjCAudioDeviceModule` is also expect
> > that the implementation of `RTCAudioDevice` will call methods related
> > to notification of audio parameters changes and audio interruption are
> > invoked on `ObjCAudioDeviceModule` thread. To facilitate this
> > requirement `RTCAudioDeviceDelegate` provides two functions to execute
> > sync and async block on `ObjCAudioDeviceModule` thread.
> > Async block could be useful when handling audio session notifications to
> > dispatch whole block re-configuring audio objects used
> > by `RTCAudioDevice` implementation.
> > Sync block could be used to make sure changes to audio parameters
> > of ADB owned by `ObjCAudioDeviceModule` are notified, before interrupted
> > playout/recording restarted.
> >
> > Bug: webrtc:14193
> > Change-Id: I5587ec6bbee3cf02bad70dd59b822feb0ada7f86
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269006
> > Reviewed-by: Henrik Andreasson <henrika@google.com>
> > Commit-Queue: Yury Yarashevich <yura.yaroshevich@gmail.com>
> > Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#37928}
>
> Bug: webrtc:14193
> Change-Id: Iaf950d24bb2394a20e50421d5122f72ce46ae840
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273380
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37946}
Bug: webrtc:14193
Change-Id: I84a6462c233daae7f662224513809b13e7218029
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273662
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37977}
This reverts commit 9a0a6a198e.
Reason for revert: Breaks upstream project
Original change's description:
> Reland "ObjC ADM: record/play implementation via RTCAudioDevice [3/3]"
>
> This is a reland of commit 2b9aaad58f
>
> Original change's description:
> > ObjC ADM: record/play implementation via RTCAudioDevice [3/3]
> >
> > # Overview
> > This CL chain exposes new API from ObjC WebRTC SDK to inject custom
> > means to play and record audio. The goal of CLs is achieved by having
> > additional implementation of `webrtc::AudioDeviceModule`
> > called `ObjCAudioDeviceModule`. The feature
> > of `ObjCAudioDeviceModule` is that it does not directly use any
> > of OS-provided audio APIs like AudioUnit, AVAudioEngine, AudioQueue,
> > AVCaptureSession etc. Instead it delegates communication with specific
> > system audio API to user-injectable audio device instance which
> > implements `RTCAudioDevice` protocol.
> > `RTCAudioDevice` is new API added to ObC WebRTC SDK in the CL chain.
> >
> > # AudioDeviceBuffer
> > `ObjCAudioDeviceModule` does conform to heavy `AudioDeviceModule`
> > interface providing stubs for unrelated methods. It also implements
> > common low-level management of audio device buffer, which glues audio
> > PCM flow to/from WebRTC.
> > `ObjCAudioDeviceModule` owns single `webrtc::AudioDeviceBuffer` which
> > with the help of two `FineAudioBuffer` (one for recording and one for
> > playout) is exchanged audio PCMs with user-provided `RTCAudioDevice`
> > instance.
> > `webrtc::AudioDeviceBuffer` is configured to work with specific audio:
> > it has to know sample rate and channels count of audio being played and
> > recorded. These formats could be different between playout and
> > recording. `ObjCAudioDeviceModule` stores current audio parameters
> > applied to `webrtc::AudioDeviceBuffer` as fields of
> > type `webrtc::AudioParameters`. `RTCAudioDevice` has it's own variable
> > audio parameters like sample rate, channels count and IO buffer
> > duration. The audio parameters of `RTCAudioDevice` must be kept in sync
> > with audio parameters applied to `webrtc::AudioDeviceBuffer`, otherwise
> > audio playout and recording will be corrupted: audio is sent only
> > partially over the wire and/or audio is played with artifacts.
> > `ObjCAudioDeviceModule` reads current `RTCAudioDevice` audio parameters
> > when playout or recording is initialized. Whenever `RTCAudioDevice`
> > audio parameters parameters are changed, there must be a notification to
> > `ObjCAudioDeviceModule` to allow it to reconfigure
> > it's `webrtc::AudioDeviceBuffer`. The notification is performed
> > via `RTCAudioDeviceDelegate` object, which is provided
> > by `ObjCAudioDeviceModule` during initialization of `RTCAudioDevice`.
> >
> > # Threading
> > `ObjCAudioDeviceModule` is stick to same thread between initialization
> > and termination. The only exception is two IO functions invoked by SDK
> > user code presumably from real-time audio IO thread.
> > Implementation of `RTCAudioDevice` may rely on the fact that all the
> > methods of `RTCAudioDevice` are called on the same thread between
> > initialization and termination. `ObjCAudioDeviceModule` is also expect
> > that the implementation of `RTCAudioDevice` will call methods related
> > to notification of audio parameters changes and audio interruption are
> > invoked on `ObjCAudioDeviceModule` thread. To facilitate this
> > requirement `RTCAudioDeviceDelegate` provides two functions to execute
> > sync and async block on `ObjCAudioDeviceModule` thread.
> > Async block could be useful when handling audio session notifications to
> > dispatch whole block re-configuring audio objects used
> > by `RTCAudioDevice` implementation.
> > Sync block could be used to make sure changes to audio parameters
> > of ADB owned by `ObjCAudioDeviceModule` are notified, before interrupted
> > playout/recording restarted.
> >
> > Bug: webrtc:14193
> > Change-Id: I5587ec6bbee3cf02bad70dd59b822feb0ada7f86
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269006
> > Reviewed-by: Henrik Andreasson <henrika@google.com>
> > Commit-Queue: Yury Yarashevich <yura.yaroshevich@gmail.com>
> > Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#37928}
>
> Bug: webrtc:14193
> Change-Id: Iaf950d24bb2394a20e50421d5122f72ce46ae840
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273380
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37946}
Bug: webrtc:14193
Change-Id: I5e18cc919ca4bb1cef7d5a11489451a0907f0d66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273486
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Andrey Logvin <landrey@google.com>
Commit-Queue: Andrey Logvin <landrey@google.com>
Cr-Commit-Position: refs/heads/main@{#37950}
This is a reland of commit 2b9aaad58f
Original change's description:
> ObjC ADM: record/play implementation via RTCAudioDevice [3/3]
>
> # Overview
> This CL chain exposes new API from ObjC WebRTC SDK to inject custom
> means to play and record audio. The goal of CLs is achieved by having
> additional implementation of `webrtc::AudioDeviceModule`
> called `ObjCAudioDeviceModule`. The feature
> of `ObjCAudioDeviceModule` is that it does not directly use any
> of OS-provided audio APIs like AudioUnit, AVAudioEngine, AudioQueue,
> AVCaptureSession etc. Instead it delegates communication with specific
> system audio API to user-injectable audio device instance which
> implements `RTCAudioDevice` protocol.
> `RTCAudioDevice` is new API added to ObC WebRTC SDK in the CL chain.
>
> # AudioDeviceBuffer
> `ObjCAudioDeviceModule` does conform to heavy `AudioDeviceModule`
> interface providing stubs for unrelated methods. It also implements
> common low-level management of audio device buffer, which glues audio
> PCM flow to/from WebRTC.
> `ObjCAudioDeviceModule` owns single `webrtc::AudioDeviceBuffer` which
> with the help of two `FineAudioBuffer` (one for recording and one for
> playout) is exchanged audio PCMs with user-provided `RTCAudioDevice`
> instance.
> `webrtc::AudioDeviceBuffer` is configured to work with specific audio:
> it has to know sample rate and channels count of audio being played and
> recorded. These formats could be different between playout and
> recording. `ObjCAudioDeviceModule` stores current audio parameters
> applied to `webrtc::AudioDeviceBuffer` as fields of
> type `webrtc::AudioParameters`. `RTCAudioDevice` has it's own variable
> audio parameters like sample rate, channels count and IO buffer
> duration. The audio parameters of `RTCAudioDevice` must be kept in sync
> with audio parameters applied to `webrtc::AudioDeviceBuffer`, otherwise
> audio playout and recording will be corrupted: audio is sent only
> partially over the wire and/or audio is played with artifacts.
> `ObjCAudioDeviceModule` reads current `RTCAudioDevice` audio parameters
> when playout or recording is initialized. Whenever `RTCAudioDevice`
> audio parameters parameters are changed, there must be a notification to
> `ObjCAudioDeviceModule` to allow it to reconfigure
> it's `webrtc::AudioDeviceBuffer`. The notification is performed
> via `RTCAudioDeviceDelegate` object, which is provided
> by `ObjCAudioDeviceModule` during initialization of `RTCAudioDevice`.
>
> # Threading
> `ObjCAudioDeviceModule` is stick to same thread between initialization
> and termination. The only exception is two IO functions invoked by SDK
> user code presumably from real-time audio IO thread.
> Implementation of `RTCAudioDevice` may rely on the fact that all the
> methods of `RTCAudioDevice` are called on the same thread between
> initialization and termination. `ObjCAudioDeviceModule` is also expect
> that the implementation of `RTCAudioDevice` will call methods related
> to notification of audio parameters changes and audio interruption are
> invoked on `ObjCAudioDeviceModule` thread. To facilitate this
> requirement `RTCAudioDeviceDelegate` provides two functions to execute
> sync and async block on `ObjCAudioDeviceModule` thread.
> Async block could be useful when handling audio session notifications to
> dispatch whole block re-configuring audio objects used
> by `RTCAudioDevice` implementation.
> Sync block could be used to make sure changes to audio parameters
> of ADB owned by `ObjCAudioDeviceModule` are notified, before interrupted
> playout/recording restarted.
>
> Bug: webrtc:14193
> Change-Id: I5587ec6bbee3cf02bad70dd59b822feb0ada7f86
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269006
> Reviewed-by: Henrik Andreasson <henrika@google.com>
> Commit-Queue: Yury Yarashevich <yura.yaroshevich@gmail.com>
> Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37928}
Bug: webrtc:14193
Change-Id: Iaf950d24bb2394a20e50421d5122f72ce46ae840
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273380
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37946}
This reverts commit 2b9aaad58f.
Reason for revert: Breaks upstream project
Original change's description:
> ObjC ADM: record/play implementation via RTCAudioDevice [3/3]
>
> # Overview
> This CL chain exposes new API from ObjC WebRTC SDK to inject custom
> means to play and record audio. The goal of CLs is achieved by having
> additional implementation of `webrtc::AudioDeviceModule`
> called `ObjCAudioDeviceModule`. The feature
> of `ObjCAudioDeviceModule` is that it does not directly use any
> of OS-provided audio APIs like AudioUnit, AVAudioEngine, AudioQueue,
> AVCaptureSession etc. Instead it delegates communication with specific
> system audio API to user-injectable audio device instance which
> implements `RTCAudioDevice` protocol.
> `RTCAudioDevice` is new API added to ObC WebRTC SDK in the CL chain.
>
> # AudioDeviceBuffer
> `ObjCAudioDeviceModule` does conform to heavy `AudioDeviceModule`
> interface providing stubs for unrelated methods. It also implements
> common low-level management of audio device buffer, which glues audio
> PCM flow to/from WebRTC.
> `ObjCAudioDeviceModule` owns single `webrtc::AudioDeviceBuffer` which
> with the help of two `FineAudioBuffer` (one for recording and one for
> playout) is exchanged audio PCMs with user-provided `RTCAudioDevice`
> instance.
> `webrtc::AudioDeviceBuffer` is configured to work with specific audio:
> it has to know sample rate and channels count of audio being played and
> recorded. These formats could be different between playout and
> recording. `ObjCAudioDeviceModule` stores current audio parameters
> applied to `webrtc::AudioDeviceBuffer` as fields of
> type `webrtc::AudioParameters`. `RTCAudioDevice` has it's own variable
> audio parameters like sample rate, channels count and IO buffer
> duration. The audio parameters of `RTCAudioDevice` must be kept in sync
> with audio parameters applied to `webrtc::AudioDeviceBuffer`, otherwise
> audio playout and recording will be corrupted: audio is sent only
> partially over the wire and/or audio is played with artifacts.
> `ObjCAudioDeviceModule` reads current `RTCAudioDevice` audio parameters
> when playout or recording is initialized. Whenever `RTCAudioDevice`
> audio parameters parameters are changed, there must be a notification to
> `ObjCAudioDeviceModule` to allow it to reconfigure
> it's `webrtc::AudioDeviceBuffer`. The notification is performed
> via `RTCAudioDeviceDelegate` object, which is provided
> by `ObjCAudioDeviceModule` during initialization of `RTCAudioDevice`.
>
> # Threading
> `ObjCAudioDeviceModule` is stick to same thread between initialization
> and termination. The only exception is two IO functions invoked by SDK
> user code presumably from real-time audio IO thread.
> Implementation of `RTCAudioDevice` may rely on the fact that all the
> methods of `RTCAudioDevice` are called on the same thread between
> initialization and termination. `ObjCAudioDeviceModule` is also expect
> that the implementation of `RTCAudioDevice` will call methods related
> to notification of audio parameters changes and audio interruption are
> invoked on `ObjCAudioDeviceModule` thread. To facilitate this
> requirement `RTCAudioDeviceDelegate` provides two functions to execute
> sync and async block on `ObjCAudioDeviceModule` thread.
> Async block could be useful when handling audio session notifications to
> dispatch whole block re-configuring audio objects used
> by `RTCAudioDevice` implementation.
> Sync block could be used to make sure changes to audio parameters
> of ADB owned by `ObjCAudioDeviceModule` are notified, before interrupted
> playout/recording restarted.
>
> Bug: webrtc:14193
> Change-Id: I5587ec6bbee3cf02bad70dd59b822feb0ada7f86
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269006
> Reviewed-by: Henrik Andreasson <henrika@google.com>
> Commit-Queue: Yury Yarashevich <yura.yaroshevich@gmail.com>
> Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37928}
Bug: webrtc:14193
Change-Id: I6e759a91664c1f6f60e862d72e45f75c51d7297a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273340
Auto-Submit: Andrey Logvin <landrey@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Andrey Logvin <landrey@google.com>
Owners-Override: Andrey Logvin <landrey@google.com>
Cr-Commit-Position: refs/heads/main@{#37931}
# Overview
This CL chain exposes new API from ObjC WebRTC SDK to inject custom
means to play and record audio. The goal of CLs is achieved by having
additional implementation of `webrtc::AudioDeviceModule`
called `ObjCAudioDeviceModule`. The feature
of `ObjCAudioDeviceModule` is that it does not directly use any
of OS-provided audio APIs like AudioUnit, AVAudioEngine, AudioQueue,
AVCaptureSession etc. Instead it delegates communication with specific
system audio API to user-injectable audio device instance which
implements `RTCAudioDevice` protocol.
`RTCAudioDevice` is new API added to ObC WebRTC SDK in the CL chain.
# AudioDeviceBuffer
`ObjCAudioDeviceModule` does conform to heavy `AudioDeviceModule`
interface providing stubs for unrelated methods. It also implements
common low-level management of audio device buffer, which glues audio
PCM flow to/from WebRTC.
`ObjCAudioDeviceModule` owns single `webrtc::AudioDeviceBuffer` which
with the help of two `FineAudioBuffer` (one for recording and one for
playout) is exchanged audio PCMs with user-provided `RTCAudioDevice`
instance.
`webrtc::AudioDeviceBuffer` is configured to work with specific audio:
it has to know sample rate and channels count of audio being played and
recorded. These formats could be different between playout and
recording. `ObjCAudioDeviceModule` stores current audio parameters
applied to `webrtc::AudioDeviceBuffer` as fields of
type `webrtc::AudioParameters`. `RTCAudioDevice` has it's own variable
audio parameters like sample rate, channels count and IO buffer
duration. The audio parameters of `RTCAudioDevice` must be kept in sync
with audio parameters applied to `webrtc::AudioDeviceBuffer`, otherwise
audio playout and recording will be corrupted: audio is sent only
partially over the wire and/or audio is played with artifacts.
`ObjCAudioDeviceModule` reads current `RTCAudioDevice` audio parameters
when playout or recording is initialized. Whenever `RTCAudioDevice`
audio parameters parameters are changed, there must be a notification to
`ObjCAudioDeviceModule` to allow it to reconfigure
it's `webrtc::AudioDeviceBuffer`. The notification is performed
via `RTCAudioDeviceDelegate` object, which is provided
by `ObjCAudioDeviceModule` during initialization of `RTCAudioDevice`.
# Threading
`ObjCAudioDeviceModule` is stick to same thread between initialization
and termination. The only exception is two IO functions invoked by SDK
user code presumably from real-time audio IO thread.
Implementation of `RTCAudioDevice` may rely on the fact that all the
methods of `RTCAudioDevice` are called on the same thread between
initialization and termination. `ObjCAudioDeviceModule` is also expect
that the implementation of `RTCAudioDevice` will call methods related
to notification of audio parameters changes and audio interruption are
invoked on `ObjCAudioDeviceModule` thread. To facilitate this
requirement `RTCAudioDeviceDelegate` provides two functions to execute
sync and async block on `ObjCAudioDeviceModule` thread.
Async block could be useful when handling audio session notifications to
dispatch whole block re-configuring audio objects used
by `RTCAudioDevice` implementation.
Sync block could be used to make sure changes to audio parameters
of ADB owned by `ObjCAudioDeviceModule` are notified, before interrupted
playout/recording restarted.
Bug: webrtc:14193
Change-Id: I5587ec6bbee3cf02bad70dd59b822feb0ada7f86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269006
Reviewed-by: Henrik Andreasson <henrika@google.com>
Commit-Queue: Yury Yarashevich <yura.yaroshevich@gmail.com>
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37928}
This reverts commit 83db78e854.
Reason for revert: Some tests in Chromium's blink no longer compile because of the change in the signature of the CreateDefaultTaskQueueFactory() function.
Original change's description:
> Add TaskQueueStdlib experiment.
>
> Bug: webrtc:14389
> Change-Id: I23c6e0ae675748ec35a99c334104dd2654995a33
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265802
> Commit-Queue: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37888}
Bug: webrtc:14389
Change-Id: If3e63d6b4ab9e838dc5020b88076a73fd29916e4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272920
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Ali Tofigh <alito@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37902}
