This is a reland of commit 9a0a6a198e8e247884fe01d7e0aa6bd425721c14
Original change's description:
> Reland "ObjC ADM: record/play implementation via RTCAudioDevice [3/3]"
>
> This is a reland of commit 2b9aaad58f56744f5c573c3b918fe072566598a5
>
> 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 0098a441e3990f80bcbe05dfce8c6e2359f7ef25.
Reason for revert: Fix chromium build break
Original change's description:
> Revert "Add plumbing to control PipeWire picker visibility"
>
> This reverts commit fbea8c519684577a38cb35b9287ba4645a905094.
>
> Reason for revert: Breaks WebRTC import into Chromium, e.g:
> https://chromium-review.googlesource.com/c/chromium/src/+/3863998/
>
> Original change's description:
> > Add plumbing to control PipeWire picker visibility
> >
> > Introduces the notion of a "delegated source list" and corresponding
> > controller. This is used by desktop capturers (currently just the
> > PipeWire capturer), who control selecting the source through their own
> > (often system-level) UI, rather than returning a source list with all
> > available options that can then be selected by the embedder.
> >
> > Adds a method to get the controller which serves to also tell embedders
> > if the capturer makes use of a delegated source list. The controller
> > currently allows the embedder to request that the delegated source list
> > be shown or hidden, and will in the future be used to expose events
> > from the source list (e.g. selection, dismissal, error).
> >
> > Bug: chromium:1351572
> > Change-Id: Ie1d36ed654013f59b8d9095deef01a4705fd5bde
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272621
> > Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> > Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#37956}
>
> Bug: chromium:1351572
> Change-Id: I06f76ab9c8bc1aa303dae177d48698951fdc5ecd
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273703
> Auto-Submit: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37964}
Bug: chromium:1351572
Change-Id: I9e5e691746b81517bf0e211d0ad5a23371ab29ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273685
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37972}
When working within chromium, we need to move up two more levels before
we can import the "find_depot_tools" module. Previously this was
managed by a loop that kept moving up until it found a directory named
'src', but this didn't work if the base-level webrtc code was not in
a directory named 'src'.
Bug: webrtc:14411
Change-Id: I2729603d6d2fd8242a1294ae5d95d946db619d0a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273561
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37971}
Ensure initial second probe can be disabled.
Can configure separate probe duration if the network state estimate is known.
Can probe immediately if network state estimate increase more than a factor
Bug: webrtc:14392
Change-Id: Iefb980f0b10c7c51db62793c3bd3f187fc67593d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273349
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37966}
This reverts commit fbea8c519684577a38cb35b9287ba4645a905094.
Reason for revert: Breaks WebRTC import into Chromium, e.g:
https://chromium-review.googlesource.com/c/chromium/src/+/3863998/
Original change's description:
> Add plumbing to control PipeWire picker visibility
>
> Introduces the notion of a "delegated source list" and corresponding
> controller. This is used by desktop capturers (currently just the
> PipeWire capturer), who control selecting the source through their own
> (often system-level) UI, rather than returning a source list with all
> available options that can then be selected by the embedder.
>
> Adds a method to get the controller which serves to also tell embedders
> if the capturer makes use of a delegated source list. The controller
> currently allows the embedder to request that the delegated source list
> be shown or hidden, and will in the future be used to expose events
> from the source list (e.g. selection, dismissal, error).
>
> Bug: chromium:1351572
> Change-Id: Ie1d36ed654013f59b8d9095deef01a4705fd5bde
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272621
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#37956}
Bug: chromium:1351572
Change-Id: I06f76ab9c8bc1aa303dae177d48698951fdc5ecd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273703
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37964}
We might be potentially blocking PipeWire initialization with call to
pw_thread_loop_wait() and waiting undefinitely for response in case
there is a fatal error.
Bug: webrtc:13429
Change-Id: If169e04f75a7d24a03a0fcd0da9ffaba8c0e2ef7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273481
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37959}
Introduces the notion of a "delegated source list" and corresponding
controller. This is used by desktop capturers (currently just the
PipeWire capturer), who control selecting the source through their own
(often system-level) UI, rather than returning a source list with all
available options that can then be selected by the embedder.
Adds a method to get the controller which serves to also tell embedders
if the capturer makes use of a delegated source list. The controller
currently allows the embedder to request that the delegated source list
be shown or hidden, and will in the future be used to expose events
from the source list (e.g. selection, dismissal, error).
Bug: chromium:1351572
Change-Id: Ie1d36ed654013f59b8d9095deef01a4705fd5bde
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272621
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37956}
Those never existed, were likely a copy-paste error in the spec
that we somehow inherited.
Bug: webrtc:11607
Change-Id: Ib4a038f061123e879f1099656273f6392f092213
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273485
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37953}
AV1 tests seem to be running fine now that we have the dependency
descriptor enabled, so remove the need for the RTP header extension
as it doesn't allow discarding frames.
Bug: webrtc:11607
Change-Id: Ifd0670ab61a5b69d0570f65ba30c352a31376992
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273488
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37952}
This reverts commit 9a0a6a198e8e247884fe01d7e0aa6bd425721c14.
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 2b9aaad58f56744f5c573c3b918fe072566598a5
>
> 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 reverts commit 021512b76a872b04e803d61f46c740ed363d641b.
Reason for revert: Breaks upstream project. It relies on the default implementation. The CL will be relanded after the migration is done. We will make sure to do it shortly.
Original change's description:
> rtpsender interface: make pure virtual again
>
> after providing default implementations in Chromium tests
>
> BUG=None
>
> Change-Id: I53bf26b3a99416f4005e7df75b9b86dfbf2489cb
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273100
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37941}
Bug: None
Change-Id: I40f27c36819365fadae32032521f7e11184bee62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273484
Owners-Override: Andrey Logvin <landrey@google.com>
Commit-Queue: Andrey Logvin <landrey@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Andrey Logvin <landrey@google.com>
Cr-Commit-Position: refs/heads/main@{#37947}
This is a reland of commit 2b9aaad58f56744f5c573c3b918fe072566598a5
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}
Replace most instances. SetAlrStartTime is set as is should be cleaned up together with the callsite.
Bug: webrtc:14404
Change-Id: I8ec532828ef665afbf08f0943465a429ab40baa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273300
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37932}
This reverts commit 2b9aaad58f56744f5c573c3b918fe072566598a5.
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}
