Strip out stream counting from AudioRendererHost.

Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl tracks the current stream count per process
and uses this for background calculations. Old UMA have been set
as obsolete and the AudioStreamsTracker class is now unused, so
removed.

BUG=670383
TEST=new browsertest
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2655413004
Cr-Commit-Position: refs/heads/master@{#449228}
Committed: https://chromium.googlesource.com/chromium/src/+/36218827374706794314c50713b5614a78562e54

[DaleCurtis, 2017-01-27 20:29:13]

Description was changed from

==========
Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl uses a pair of AudioStreamTracker objects
for UMA and background priority calculation purposes.

BUG=670383
TEST=none
==========

to

==========
Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl uses a pair of AudioStreamTracker objects
for UMA and background priority calculation purposes.

BUG=670383
TEST=none
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[DaleCurtis, 2017-01-27 20:30:31]

dalecurtis@chromium.org changed reviewers:
+ maxmorin@chromium.org, olka@chromium.org

[DaleCurtis, 2017-01-27 20:30:32]

If content/ folk would prefer we iterate over WebContents for this information
that's fine with me too.

[Max Morin, 2017-01-30 11:47:08]

lgtm % comment

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_process_host_impl.cc:1579:
UpdateProcessPriority();
It probably makes sense to only UpdateProcessPriority if the value of
audio_streams_tracker_.has_streams() changed.

[o1ka, 2017-01-30 12:19:13]

This looks really nice.

I got lost figuring out relations between RendererPocessHost and WebContents.
This code
[https://cs.chromium.org/chromium/src/content/browser/media/audio_stream_monitor.cc?dr=C&sq=package:chromium&rcl=1485491011&l=25]
assumes that we may have RPH without WebContents. Is it true?
If so, we may have a problem.

https://codereview.chromium.org/2655413004/diff/1/media/audio/audio_streams_t...
File media/audio/audio_streams_tracker.h (right):

https://codereview.chromium.org/2655413004/diff/1/media/audio/audio_streams_t...
media/audio/audio_streams_tracker.h:33: size_t max_stream_count() const { return
max_stream_count_; }
These two need thread checks.

[DaleCurtis, 2017-01-30 21:12:18]

dalecurtis@chromium.org changed reviewers:
+ ncarter@chromium.org

[DaleCurtis, 2017-01-30 21:12:19]

+ncarter for content/ review and olka@'s question: "Can a RenderProcessHostImpl
exist without a WebContents?"

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
content/browser/media/audio_stream_monitor.cc:90: RenderProcessHostImpl*
render_process_host =
+ncarter for content/ review. Is it possible for this to ever return null if
l.85 returns a value?

https://codereview.chromium.org/2655413004/diff/1/media/audio/audio_streams_t...
File media/audio/audio_streams_tracker.h (right):

https://codereview.chromium.org/2655413004/diff/1/media/audio/audio_streams_t...
media/audio/audio_streams_tracker.h:33: size_t max_stream_count() const { return
max_stream_count_; }
On 2017/01/30 at 12:19:13, o1ka wrote:
> These two need thread checks.

Okay, but they can't be hacker_style() then, so I'll have to rename both.

[ncarter (slow), 2017-01-31 18:33:11]

nick@chromium.org changed reviewers:
+ nick@chromium.org

[ncarter (slow), 2017-01-31 18:33:12]

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
content/browser/media/audio_stream_monitor.cc:90: RenderProcessHostImpl*
render_process_host =
On 2017/01/30 21:12:19, DaleCurtis wrote:
> +ncarter for content/ review. Is it possible for this to ever return null if
> l.85 returns a value?

This is safe, given the implementation of AudioStreamMonitorFromRenderFrame:

 WebContentsImpl* const web_contents =
      static_cast<WebContentsImpl*>(WebContents::FromRenderFrameHost(
          RenderFrameHost::FromID(render_process_id, render_frame_id)));

Since this does a lookup via RenderFrameHost::FromID(), we know there's a valid
RenderFrameHost* with this ID tuple, and a RenderFrameHost* keeps its
RenderProcessHost alive (via AddRoute/RemoveRoute).

However, this would be easier to see and verify if you just retained the
RenderFrameHost ptr used to lookup the WebContents, and called GetProcess() to
obtain the RPH. That would also be a touch faster.

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
content/browser/media/audio_stream_monitor.cc:120:
render_process_host->OnAudioStreamRemoved();
How confident are you that this perfectly balances the Added operation?

Does this function get executed if the process is killed (e.g. if you kill it
via task manager)?

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_process_host_impl.cc:800:
g_audio_streams_tracker.Get().max_stream_count(), 1, 100, 101);
This logging used to happen each time a MessageFilter was destroyed; now it
happens each time a RenderProcessHostImpl is destroyed. This is not the same:
each type of MessageFilter can be created and destroyed multiple times for a
particular RenderProcessHostImpl -- in particular, this happens in the crash /
sad tab case -- the RenderProcessHostImpl stays around, but
CreateMessageFilters() occurs again, creating a second generation of message
filters for the RPH instance, if the tab is reloaded.

So this isn't the same as the old behavior. Are you sure it's what you intend?
In particular I worry that if you force-kill a process that has active audio
streams, will the count actually fall to zero, or will you wind up in an
incorrect state?

It would be good to have browsertests for that case. histogram_tester.h in base
can be useful for that sort of test.

[ncarter (slow), 2017-01-31 18:35:19]

Also, as a meta-comment, moving audio-specific stuff into RPH seems like the
wrong direction.

I don't understand how this logging change is necessary for mojofication. Why
can't the mojo-ported version of the message filter do the logging?

[DaleCurtis, 2017-01-31 22:08:31]

dalecurtis@chromium.org changed reviewers:
+ grunell@chromium.org

[DaleCurtis, 2017-01-31 22:08:31]

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_process_host_impl.cc:800:
g_audio_streams_tracker.Get().max_stream_count(), 1, 100, 101);
On 2017/01/31 at 18:33:12, ncarter wrote:
> This logging used to happen each time a MessageFilter was destroyed; now it
happens each time a RenderProcessHostImpl is destroyed. This is not the same:
each type of MessageFilter can be created and destroyed multiple times for a
particular RenderProcessHostImpl -- in particular, this happens in the crash /
sad tab case -- the RenderProcessHostImpl stays around, but
CreateMessageFilters() occurs again, creating a second generation of message
filters for the RPH instance, if the tab is reloaded.
> 
> So this isn't the same as the old behavior. Are you sure it's what you intend?
In particular I worry that if you force-kill a process that has active audio
streams, will the count actually fall to zero, or will you wind up in an
incorrect state?
> 
> It would be good to have browsertests for that case. histogram_tester.h in
base can be useful for that sort of test.

Ah, I didn't know multiple sets of MessageFilter's can be created like this. The
spirit of the logging was render process shutdown, though the implementation was
not. I'd actually like to just delete these metrics; I don't think they're all
that useful. +grunell for commentary.

[DaleCurtis, 2017-02-03 00:43:21]

Ping grunell

[Henrik Grunell, 2017-02-03 08:52:20]

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_process_host_impl.cc:800:
g_audio_streams_tracker.Get().max_stream_count(), 1, 100, 101);
On 2017/01/31 22:08:31, DaleCurtis wrote:
> On 2017/01/31 at 18:33:12, ncarter wrote:
> > This logging used to happen each time a MessageFilter was destroyed; now it
> happens each time a RenderProcessHostImpl is destroyed. This is not the same:
> each type of MessageFilter can be created and destroyed multiple times for a
> particular RenderProcessHostImpl -- in particular, this happens in the crash /
> sad tab case -- the RenderProcessHostImpl stays around, but
> CreateMessageFilters() occurs again, creating a second generation of message
> filters for the RPH instance, if the tab is reloaded.
> > 
> > So this isn't the same as the old behavior. Are you sure it's what you
intend?
> In particular I worry that if you force-kill a process that has active audio
> streams, will the count actually fall to zero, or will you wind up in an
> incorrect state?
> > 
> > It would be good to have browsertests for that case. histogram_tester.h in
> base can be useful for that sort of test.
> 
> Ah, I didn't know multiple sets of MessageFilter's can be created like this.
The
> spirit of the logging was render process shutdown, though the implementation
was
> not. I'd actually like to just delete these metrics; I don't think they're all
> that useful. +grunell for commentary.

Sorry Dale, I missed that I was supposed to reply to this. I think we can remove
these metrics. It was added for the mixing experiment which is deprecated in its
current form. I don't see any reason to keep it around. If we'll work on
changing the mixing later on, we can re-add these or other metrics.

Olga and Max: are they useful in the separate process work? (I doubt that.)

[Max Morin, 2017-02-03 08:53:21]

On 2017/02/03 08:52:20, Henrik Grunell wrote:
> Olga and Max: are they useful in the separate process work? (I doubt that.)

No, please remove them :)

[DaleCurtis, 2017-02-06 22:18:43]

Description was changed from

==========
Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl uses a pair of AudioStreamTracker objects
for UMA and background priority calculation purposes.

BUG=670383
TEST=none
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl tracks the current stream count per process
and uses this for background calculations. Old UMA have been set
as obsolete and the AudioStreamsTracker class is now unused, so
removed.

BUG=670383
TEST=new browsertest
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[DaleCurtis, 2017-02-06 22:19:03]

Okay this is all fixed up with a test now and removes even more code (yay!)

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
content/browser/media/audio_stream_monitor.cc:90: RenderProcessHostImpl*
render_process_host =
On 2017/01/31 at 18:33:12, ncarter (away) wrote:
> On 2017/01/30 21:12:19, DaleCurtis wrote:
> > +ncarter for content/ review. Is it possible for this to ever return null if
> > l.85 returns a value?
> 
> This is safe, given the implementation of AudioStreamMonitorFromRenderFrame:
> 
>  WebContentsImpl* const web_contents =
>       static_cast<WebContentsImpl*>(WebContents::FromRenderFrameHost(
>           RenderFrameHost::FromID(render_process_id, render_frame_id)));
> 
> Since this does a lookup via RenderFrameHost::FromID(), we know there's a
valid RenderFrameHost* with this ID tuple, and a RenderFrameHost* keeps its
RenderProcessHost alive (via AddRoute/RemoveRoute).
> 
> However, this would be easier to see and verify if you just retained the
RenderFrameHost ptr used to lookup the WebContents, and called GetProcess() to
obtain the RPH. That would also be a touch faster.

Replaced all of this with a helper function. We can't use
RenderFrameHost::FromID here since we need to always send this even if the frame
host has gone away. The only way to do that seems to be using RPH::FromID().

https://codereview.chromium.org/2655413004/diff/1/content/browser/media/audio...
content/browser/media/audio_stream_monitor.cc:120:
render_process_host->OnAudioStreamRemoved();
On 2017/01/31 at 18:33:12, ncarter (away) wrote:
> How confident are you that this perfectly balances the Added operation?
> 
> Does this function get executed if the process is killed (e.g. if you kill it
via task manager)?

Test added; it was incorrect before, but is correct now. The ordering of process
checks was wrong.

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_process_host_impl.cc:800:
g_audio_streams_tracker.Get().max_stream_count(), 1, 100, 101);
On 2017/02/03 at 08:52:20, Henrik Grunell wrote:
> On 2017/01/31 22:08:31, DaleCurtis wrote:
> > On 2017/01/31 at 18:33:12, ncarter wrote:
> > > This logging used to happen each time a MessageFilter was destroyed; now
it
> > happens each time a RenderProcessHostImpl is destroyed. This is not the
same:
> > each type of MessageFilter can be created and destroyed multiple times for a
> > particular RenderProcessHostImpl -- in particular, this happens in the crash
/
> > sad tab case -- the RenderProcessHostImpl stays around, but
> > CreateMessageFilters() occurs again, creating a second generation of message
> > filters for the RPH instance, if the tab is reloaded.
> > > 
> > > So this isn't the same as the old behavior. Are you sure it's what you
intend?
> > In particular I worry that if you force-kill a process that has active audio
> > streams, will the count actually fall to zero, or will you wind up in an
> > incorrect state?
> > > 
> > > It would be good to have browsertests for that case. histogram_tester.h in
> > base can be useful for that sort of test.
> > 
> > Ah, I didn't know multiple sets of MessageFilter's can be created like this.
The
> > spirit of the logging was render process shutdown, though the implementation
was
> > not. I'd actually like to just delete these metrics; I don't think they're
all
> > that useful. +grunell for commentary.
> 
> Sorry Dale, I missed that I was supposed to reply to this. I think we can
remove these metrics. It was added for the mixing experiment which is deprecated
in its current form. I don't see any reason to keep it around. If we'll work on
changing the mixing later on, we can re-add these or other metrics.
> 
> Olga and Max: are they useful in the separate process work? (I doubt that.)

Deleted, thanks!

https://codereview.chromium.org/2655413004/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_process_host_impl.cc:1579:
UpdateProcessPriority();
On 2017/01/30 at 11:47:07, Max Morin wrote:
> It probably makes sense to only UpdateProcessPriority if the value of
audio_streams_tracker_.has_streams() changed.

UpdateProcessPriority() takes care of this.

https://codereview.chromium.org/2655413004/diff/1/media/audio/audio_streams_t...
File media/audio/audio_streams_tracker.h (right):

https://codereview.chromium.org/2655413004/diff/1/media/audio/audio_streams_t...
media/audio/audio_streams_tracker.h:33: size_t max_stream_count() const { return
max_stream_count_; }
On 2017/01/30 at 21:12:19, DaleCurtis wrote:
> On 2017/01/30 at 12:19:13, o1ka wrote:
> > These two need thread checks.
> 
> Okay, but they can't be hacker_style() then, so I'll have to rename both.

Deleted this whole class instead. It's overkill for tracking a single int for
one user now.

[DaleCurtis, 2017-02-06 22:19:11]

The CQ bit was checked by dalecurtis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-06 22:19:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-06 23:04:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-06 23:04:44]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[DaleCurtis, 2017-02-07 01:09:00]

The CQ bit was checked by dalecurtis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-07 01:10:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-07 03:06:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-07 03:06:12]

Dry run: This issue passed the CQ dry run.

[Henrik Grunell, 2017-02-07 06:56:28]

LGTM for removal of the two metrics and the AudioStreamsTracker.

[o1ka, 2017-02-07 09:38:02]

\o/ lgtm

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
content/browser/media/audio_stream_monitor.cc:210: if (--active_streams_ == 0) {
DCHECK(active_streams_ > 0)?

https://codereview.chromium.org/2655413004/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_process_host_impl.cc:1581:
--audio_stream_count_;
DCHECK(audio_stream_count_ > 0)?

[Max Morin, 2017-02-07 11:51:20]

Still lgtm, just a small comment.

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
content/browser/media/audio_stream_monitor.cc:132:
DCHECK(!read_power_callback.is_null());
DCHECK that stream_id is not already monitored? And that it is monitored before
stopping monitoring.

[DaleCurtis, 2017-02-07 22:08:22]

dalecurtis@chromium.org changed reviewers:
- ncarter@chromium.org

[DaleCurtis, 2017-02-07 22:09:16]

dalecurtis@chromium.org changed reviewers:
+ rkaplow@chromium.org

[DaleCurtis, 2017-02-07 22:09:17]

DCHECKs added. nick@ PTAL. +rkaplow for histograms.xml obsoletion.

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
content/browser/media/audio_stream_monitor.cc:210: if (--active_streams_ == 0) {
On 2017/02/07 at 09:38:02, o1ka (CET) wrote:
> DCHECK(active_streams_ > 0)?

Done.

https://codereview.chromium.org/2655413004/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2655413004/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_process_host_impl.cc:1581:
--audio_stream_count_;
On 2017/02/07 at 09:38:02, o1ka (CET) wrote:
> DCHECK(audio_stream_count_ > 0)?

Done.

[rkaplow, 2017-02-08 15:28:28]

lgtm

[DaleCurtis, 2017-02-08 23:15:10]

dalecurtis@chromium.org changed reviewers:
+ avi@chromium.org
- nick@chromium.org

[DaleCurtis, 2017-02-08 23:15:10]

nick=>avi due to OOO.

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
File content/browser/media/audio_stream_monitor.cc (right):

https://codereview.chromium.org/2655413004/diff/40001/content/browser/media/a...
content/browser/media/audio_stream_monitor.cc:132:
DCHECK(!read_power_callback.is_null());
On 2017/02/07 at 11:51:19, Max Morin wrote:
> DCHECK that stream_id is not already monitored? And that it is monitored
before stopping monitoring.

Done.

[Avi (use Gerrit), 2017-02-09 02:47:39]

lgtm

Looks reasonable.

[DaleCurtis, 2017-02-09 03:03:39]

Thanks for review!

[DaleCurtis, 2017-02-09 03:03:42]

The CQ bit was checked by dalecurtis@chromium.org

[DaleCurtis, 2017-02-09 03:03:43]

The patchset sent to the CQ was uploaded after l-g-t-m from
grunell@chromium.org, maxmorin@chromium.org, olka@chromium.org
Link to the patchset: https://codereview.chromium.org/2655413004/#ps80001
(title: "Add moar DCHECKs.")

[commit-bot: I haz the power, 2017-02-09 03:04:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-09 06:35:24]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1486609422431550,
"parent_rev": "307f9f29d879afce43fe94d03616ef3c7a87971d", "commit_rev":
"36218827374706794314c50713b5614a78562e54"}

[commit-bot: I haz the power, 2017-02-09 06:36:04]

Description was changed from

==========
Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl tracks the current stream count per process
and uses this for background calculations. Old UMA have been set
as obsolete and the AudioStreamsTracker class is now unused, so
removed.

BUG=670383
TEST=new browsertest
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Strip out stream counting from AudioRendererHost.

This allows us to prepare the way for the mojo audio subsystem by
moving out pieces from the AudioRendererHost.

We already have a AudioStreamMonitor delivering notifications to
WebContents, so now it just also delivers a notification to the
RenderProcessHostImpl when a stream is started.

RenderProcessHostImpl tracks the current stream count per process
and uses this for background calculations. Old UMA have been set
as obsolete and the AudioStreamsTracker class is now unused, so
removed.

BUG=670383
TEST=new browsertest
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2655413004
Cr-Commit-Position: refs/heads/master@{#449228}
Committed:
https://chromium.googlesource.com/chromium/src/+/36218827374706794314c50713b5...
==========

[commit-bot: I haz the power, 2017-02-09 06:36:06]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/36218827374706794314c50713b5...