RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships: https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-zwo/edit?usp=sharing

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881, 577874
TBR=olka@chromium.org,perkj@chromium.org,tommi@chromium.org,nick@chromium.org

Committed: https://crrev.com/7f68ab4de698d37bb159682995d7bfbf6d701b67
Cr-Commit-Position: refs/heads/master@{#393343}

[miu, 2016-05-12 18:56:56]

Patchset #1 (id:1) has been deleted

[miu, 2016-05-12 19:00:27]

Description was changed from

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots.

Description of original change:

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
==========

to

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
==========

[miu, 2016-05-12 19:25:15]

miu@chromium.org changed reviewers:
+ mcasas@chromium.org

[miu, 2016-05-12 19:25:16]

mcasas: Would you please sanity-check the difference between PS2 and PS1 before
I try to re-land this change?

[miu, 2016-05-12 19:25:55]

miu@chromium.org changed reviewers:
+ nick@chromium.org, olka@chromium.org, perkj@chromium.org, tommi@chromium.org

[miu, 2016-05-12 19:27:13]

Description was changed from

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
==========

to

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
TBR=olka@chromium.org,perkj@chromium.org,tommi@chromium.org,nick@chromium.org
==========

[mcasas, 2016-05-12 19:36:08]

On 2016/05/12 19:25:16, miu wrote:
> mcasas: Would you please sanity-check the difference between PS2 and PS1
before
> I try to re-land this change?

LGTM from my perspective.

[miu, 2016-05-12 19:40:35]

On 2016/05/12 19:36:08, mcasas wrote:
> On 2016/05/12 19:25:16, miu wrote:
> > mcasas: Would you please sanity-check the difference between PS2 and PS1
> before
> > I try to re-land this change?
> 
> LGTM from my perspective.

Thanks, mcasas.

FYI to all: I did re-test these changes locally. Running TSAN locally also
confirmed the deadlock issue was resolved.

[miu, 2016-05-12 19:40:44]

The CQ bit was checked by miu@chromium.org

[commit-bot: I haz the power, 2016-05-12 19:41:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1977553002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1977553002/40001

[commit-bot: I haz the power, 2016-05-12 20:29:14]

Description was changed from

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
TBR=olka@chromium.org,perkj@chromium.org,tommi@chromium.org,nick@chromium.org
==========

to

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
TBR=olka@chromium.org,perkj@chromium.org,tommi@chromium.org,nick@chromium.org
==========

[commit-bot: I haz the power, 2016-05-12 20:29:16]

Committed patchset #2 (id:40001)

[commit-bot: I haz the power, 2016-05-12 20:30:37]

Description was changed from

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
TBR=olka@chromium.org,perkj@chromium.org,tommi@chromium.org,nick@chromium.org
==========

to

==========
RELAND: MediaStream audio: Refactor 3 separate "glue" impls into one.

This is a re-land of https://codereview.chromium.org/1834323002 with
locking changes made in ProcessedLocalAudioSource to mitigate a deadlock
condition at shutdown, identified by the TSAN bots. The root-cause of
the issue was due to both AudioInputDevice::Thread and PLAS acquiring
two locks in a different order under certain circumstances. The solution
to this was to eliminate locking in PLAS::Capture() and take a
different approach to thread-safe concurrency in PLAS::SetVolume().

-------Description of original change follows-------

This is a refactoring of the MediaStreamAudioSource/Track object graph
such that life-cycle and audio flow control are unified into a single
architecture.  Previously, each of three implementations solved this
same problem in three different ways; and this has made it difficult to
maintain the code in src/content/renderer/media across all product
features, WebRTC or otherwise.

Diagram of post-refactoring class relationships:
https://docs.google.com/drawings/d/1yTsXvRMIyMlXjIEeQOVqXPxMPWgekB5ePWUVSI5-z...

The new architeture is as follows:

1. MediaStreamAudioSource becomes a base class implementation for
creating MediaStreamAudioTracks and delivering audio to them from the
source (i.e., an AudioInputDevice, a PeerConnection remote source, or a
WebAudio source).  All of its methods are now assumed to be run on the
main thread, while audio flow may optionally occur on a separate
thread.

2. MediaStreamAudioTrack becomes a base class implementation for
connecting/disconnecting MediaStreamAudioSinks, and delivering audio to
them from the source.

3. Both MediaStreamAudioSource and MediaStreamAudioTrack are owned by
their blink counterparts (WebMediaStreamSource and WebMediaStreamTrack),
and their destruction may safely occur any time the blink implementation
requires it.

Following the new architeture, the refactoring is:

1. WebRtcAudioCapturer becomes a sub-class of MediaStreamAudioSource and
is renamed to ProcessedLocalAudioSource.  This new class owns and
manages the WebRTC-specific audio processing on the source data.  Also:
a) Significant implementation from PeerConnectionDependencyFactory was
consolidated/moved to this class.  b) The "EnablePeerConnectionMode"
functionality, which re-started the audio input with a different buffer
size, has been removed to simplify the implementation.  Now, buffer size
is determined BEFORE the first time the audio input device is started.
c) Currently, all local audio sources (i.e., via AudioInputDevice) are
routed through this pipeline, but a soon-upcoming change will split the
WebRTC-specific cases from the ones that should not go through audio
processing.

2. MediaStreamRemoteAudioTrack becomes a sub-class of
MediaStreamAudioSource and is renamed to
PeerConnectionRemoteAudioSource.  This new class owns and manages the
flow of audio data from a PeerConnection into the MediaStream
framework.

3. WebAudioCapturer becomes a sub-class of MediaStreamAudioSource and is
renamed to WebAudioMediaStreamSource.  As a
blink::WebAudioDestinationConsumer, it manages the flow of audio from a
WebAudio destination node into the MediaStream framework.

BUG=577881,577874
TBR=olka@chromium.org,perkj@chromium.org,tommi@chromium.org,nick@chromium.org

Committed: https://crrev.com/7f68ab4de698d37bb159682995d7bfbf6d701b67
Cr-Commit-Position: refs/heads/master@{#393343}
==========

[commit-bot: I haz the power, 2016-05-12 20:30:38]

Patchset 2 (id:??) landed as
https://crrev.com/7f68ab4de698d37bb159682995d7bfbf6d701b67
Cr-Commit-Position: refs/heads/master@{#393343}