Intiialize AudioManager and related class lazily

Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager takes about 10KB of memory.
This is only needed when the first renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479
Committed: https://crrev.com/c8569a7cd8c3cb6f9cd22467e084860721ceadd7
Cr-Commit-Position: refs/heads/master@{#404014}

[qinmin, 2016-06-17 23:56:04]

qinmin@chromium.org changed reviewers:
+ sievers@chromium.org

[qinmin, 2016-06-17 23:56:05]

PTAL

[qinmin, 2016-06-17 23:56:18]

The CQ bit was checked by qinmin@chromium.org

[qinmin, 2016-06-17 23:56:20]

The CQ bit was unchecked by qinmin@chromium.org

[qinmin, 2016-06-17 23:56:25]

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

[commit-bot: I haz the power, 2016-06-17 23:56:38]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2077983003/1

[no sievers, 2016-06-18 00:17:20]

looks like a good idea. did you run it by some desktop folks though to make sure
there are no hidden assumptions somehow about this being initialized early?

> Creating the AudioManager is quite costly,

nit: could you update it to say 'costly in terms of memory'?

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
File content/browser/browser_main_loop.cc (right):

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
content/browser/browser_main_loop.cc:1495: media_stream_manager_.reset(new
MediaStreamManager(audio_manager_.get()));
nit: or just write newMediaStreamManager(GetAudioManager());

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
content/browser/browser_main_loop.cc:1505: audio_manager_.get(),
media_stream_manager_.get()));
nit: same here

[DaleCurtis, 2016-06-18 00:21:13]

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

[DaleCurtis, 2016-06-18 00:21:14]

This is not true, the AudioManager has several callers in the browser process.

[DaleCurtis, 2016-06-18 00:21:37]

Can you elaborate on the cost here? On most platforms it does nothing except
start a thread and post a task.

[DaleCurtis, 2016-06-18 00:23:05]

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

[DaleCurtis, 2016-06-18 00:23:05]

+tommi

[commit-bot: I haz the power, 2016-06-18 00:29:20]

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

[commit-bot: I haz the power, 2016-06-18 00:29:21]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[qinmin, 2016-06-18 04:04:24]

On 2016/06/18 00:21:14, DaleCurtis wrote:
> This is not true, the AudioManager has several callers in the browser process.

Yes，there is callers in browser process. But we don't need AudioManager if there
is no RenderProcessHost. 
For download resumption, we only need to create the browser process, and there
is no renderer process. So we can delay AudioManager creation util the first
renderer is created.

[qinmin, 2016-06-18 04:21:02]

On 2016/06/18 00:21:37, DaleCurtis wrote:
> Can you elaborate on the cost here? On most platforms it does nothing except
> start a thread and post a task.

When AudioThread is created, 2 tasks are posted: RecordAudioThreadStatus and
UpdateLastAudioThreadTimeTick.
Both will allocate some memory and totally they contributed about 10KB to
overall memory usage.

[qinmin, 2016-06-18 04:23:00]

Description was changed from

==========
Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager is quite costly, it is only needed when
renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479
==========

to

==========
Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager takes about 10KB of memory.
This is only needed when the first renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479
==========

[tommi (sloooow) - chröme, 2016-06-18 13:49:03]

are the bot failures related?

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
File content/browser/browser_main_loop.cc (right):

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
content/browser/browser_main_loop.cc:1450: media::AudioManager*
BrowserMainLoop::GetAudioManager() {
make sure this always runs on the same thread

[DaleCurtis, 2016-06-20 16:22:35]

On 2016/06/18 at 04:04:24, qinmin wrote:
> On 2016/06/18 00:21:14, DaleCurtis wrote:
> > This is not true, the AudioManager has several callers in the browser
process.
> 
> Yes，there is callers in browser process. But we don't need AudioManager if
there is no RenderProcessHost. 
> For download resumption, we only need to create the browser process, and there
is no renderer process. So we can delay AudioManager creation util the first
renderer is created.

No, I mean there are callers into this code before there is a renderer -- at
least on ChromeOS, which is likely why some of those tests are failing. The AM
code is used to play startup sounds during boot. I believe there are (or were)
callers on other platforms which made use of the AM code as well (copresence
maybe?).

[DaleCurtis, 2016-06-20 16:23:25]

On 2016/06/20 at 16:22:35, DaleCurtis wrote:
> On 2016/06/18 at 04:04:24, qinmin wrote:
> > On 2016/06/18 00:21:14, DaleCurtis wrote:
> > > This is not true, the AudioManager has several callers in the browser
process.
> > 
> > Yes，there is callers in browser process. But we don't need AudioManager if
there is no RenderProcessHost. 
> > For download resumption, we only need to create the browser process, and
there is no renderer process. So we can delay AudioManager creation util the
first renderer is created.
> 
> No, I mean there are callers into this code before there is a renderer -- at
least on ChromeOS, which is likely why some of those tests are failing. The AM
code is used to play startup sounds during boot. I believe there are (or were)
callers on other platforms which made use of the AM code as well (copresence
maybe?).

But to be clear, if you can solve these concerns, doing this is fine with me.

[qinmin, 2016-06-20 23:43:49]

Patchset #2 (id:20001) has been deleted

[qinmin, 2016-06-20 23:45:29]

Chatted with sievers@, and agree to limit the lazy initialization to Android
only.

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
File content/browser/browser_main_loop.cc (right):

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
content/browser/browser_main_loop.cc:1450: media::AudioManager*
BrowserMainLoop::GetAudioManager() {
On 2016/06/18 13:49:03, tommi-chrömium wrote:
> make sure this always runs on the same thread

Done.

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
content/browser/browser_main_loop.cc:1495: media_stream_manager_.reset(new
MediaStreamManager(audio_manager_.get()));
On 2016/06/18 00:17:20, sievers wrote:
> nit: or just write newMediaStreamManager(GetAudioManager());

no longer needed with the new patch

https://codereview.chromium.org/2077983003/diff/1/content/browser/browser_mai...
content/browser/browser_main_loop.cc:1505: audio_manager_.get(),
media_stream_manager_.get()));
On 2016/06/18 00:17:20, sievers wrote:
> nit: same here

no longer needed with the new patch

[no sievers, 2016-06-20 23:50:59]

lgtm if Dale is happy too

https://codereview.chromium.org/2077983003/diff/40001/content/browser/browser...
File content/browser/browser_main_loop.cc (right):

https://codereview.chromium.org/2077983003/diff/40001/content/browser/browser...
content/browser/browser_main_loop.cc:1233: TRACE_EVENT0("startup",
"BrowserThreadsStarted::InitMediaComponents");
nit: maybe move the trace event into the function where we actually init?

[DaleCurtis, 2016-06-21 00:16:32]

I'd prefer not to add more one-offs just for Android. Sorry to ask a
probably-desktop centric question, but is this really worth it for 10kb? The
risk is that we're adding yet another feature that works slightly differently
when run on different platforms.

By deferring this you're deferring an entire chain of initialization. If we're
going to do this, I'd prefer we did it on all platforms where we have more test
coverage for what can go wrong. I.e., have you looked into the failures that
have occurred so far? Are they all ChromeOS related or is there a larger issue
hiding?

[no sievers, 2016-06-21 00:19:17]

On 2016/06/21 00:16:32, DaleCurtis wrote:
> I'd prefer not to add more one-offs just for Android. 

Good point. If you want different behavior, why not handle that in
audio_manager_android.cc (and lazily init there)?

[qinmin, 2016-06-21 04:20:05]

On 2016/06/21 00:16:32, DaleCurtis wrote:
> I'd prefer not to add more one-offs just for Android. Sorry to ask a
> probably-desktop centric question, but is this really worth it for 10kb? The
> risk is that we're adding yet another feature that works slightly differently
> when run on different platforms.
> 
> By deferring this you're deferring an entire chain of initialization. If we're
> going to do this, I'd prefer we did it on all platforms where we have more
test
> coverage for what can go wrong. I.e., have you looked into the failures that
> have occurred so far? Are they all ChromeOS related or is there a larger issue
> hiding?

For a regular browser session, 10KB is not really worth saving. But for
background download resumption(no GPU, no Renderer), 10 KB is something we
should not skip. Especially the bigger the memory footprint, the higher the
chance to get killed by OS. Currently Background resumption takes about 13M
private dirty currently, and we really want to bring it down to 10MB. There are
not a lot of big  items we can shrink immediately to get to the target, so
saving small pieces here and there would helps.

The failure on chromeOS is caused by that ChromeOS needs AudioManager to create
a SoundsManager object during startup. If I initialize AudioManager before
SoundsManager is created, the all the tests will pass. However, chromeOS is
under chrome/browser, and browser_main_loop is in content/browser. So I have to
create a static interface in content/public, and let chromeOS call that function
to initialize the AudioManager.  Not sure if this is the right way to do

[qinmin, 2016-06-21 17:27:49]

On 2016/06/21 00:19:17, sievers wrote:
> On 2016/06/21 00:16:32, DaleCurtis wrote:
> > I'd prefer not to add more one-offs just for Android. 
> 
> Good point. If you want different behavior, why not handle that in
> audio_manager_android.cc (and lazily init there)?

The extra memory is introduced by AudioManager::StartHangMonitor(). If we can
lazily call that function, then it would also be ok.
@dalecurtis, the hang timer is disabled on mac. Do we need it on Android? Since
Chrome interact with openSL ES on the audio thread, i guess that it is still
needed. 
But can we lazily start monitoring until the first renderer is created?

[DaleCurtis, 2016-06-21 19:27:10]

On 2016/06/21 at 17:27:49, qinmin wrote:
> On 2016/06/21 00:19:17, sievers wrote:
> > On 2016/06/21 00:16:32, DaleCurtis wrote:
> > > I'd prefer not to add more one-offs just for Android. 
> > 
> > Good point. If you want different behavior, why not handle that in
> > audio_manager_android.cc (and lazily init there)?
> 
> The extra memory is introduced by AudioManager::StartHangMonitor(). If we can
lazily call that function, then it would also be ok.
> @dalecurtis, the hang timer is disabled on mac. Do we need it on Android?
Since Chrome interact with openSL ES on the audio thread, i guess that it is
still needed. 
> But can we lazily start monitoring until the first renderer is created?

If it's just the hang monitor can you disable that only for background sessions?
That is only reporting a UMA right now and it's sitting at 100% okay right now.

[qinmin, 2016-06-21 21:21:57]

On 2016/06/21 19:27:10, DaleCurtis wrote:
> On 2016/06/21 at 17:27:49, qinmin wrote:
> > On 2016/06/21 00:19:17, sievers wrote:
> > > On 2016/06/21 00:16:32, DaleCurtis wrote:
> > > > I'd prefer not to add more one-offs just for Android. 
> > > 
> > > Good point. If you want different behavior, why not handle that in
> > > audio_manager_android.cc (and lazily init there)?
> > 
> > The extra memory is introduced by AudioManager::StartHangMonitor(). If we
can
> lazily call that function, then it would also be ok.
> > @dalecurtis, the hang timer is disabled on mac. Do we need it on Android?
> Since Chrome interact with openSL ES on the audio thread, i guess that it is
> still needed. 
> > But can we lazily start monitoring until the first renderer is created?
> 
> If it's just the hang monitor can you disable that only for background
sessions?
> That is only reporting a UMA right now and it's sitting at 100% okay right
now.

PTAL again. Changed the implementation to delay calling of
AudioManager::StartHangMonitor().
The new patch also delays creation of the java object, and moving the change
into AudioManagerAndroid.

[DaleCurtis, 2016-06-21 21:27:44]

Hmm, why not just always defer StartHangMonitor until a render process is
attached? I also think if you want to defer JNI creation you can just have an
internal method in AudioManagerAndroid which handles that upon first call into
any JNI using methods.

[DaleCurtis, 2016-06-21 21:28:49]

On 2016/06/21 at 21:27:44, DaleCurtis wrote:
> Hmm, why not just always defer StartHangMonitor until a render process is
attached? I also think if you want to defer JNI creation you can just have an
internal method in AudioManagerAndroid which handles that upon first call into
any JNI using methods.

Note: You probably want to take some care about the AudioManagerAndroid
destructor too. It will always try to call into AudioManager::close() even if
initialize never started.

[qinmin, 2016-06-21 22:05:59]

On 2016/06/21 21:28:49, DaleCurtis wrote:
> On 2016/06/21 at 21:27:44, DaleCurtis wrote:
> > Hmm, why not just always defer StartHangMonitor until a render process is
> attached? I also think if you want to defer JNI creation you can just have an
> internal method in AudioManagerAndroid which handles that upon first call into
> any JNI using methods.
> 

Ok, Deferred StartHangMonitor on all platforms. For JNI creation, we cannot
defer it as the JNI inti() call will initialize some intent broadcast receivers.

So defering it will disable Chrome from listening to those intents until audio
is played.

> Note: You probably want to take some care about the AudioManagerAndroid
> destructor too. It will always try to call into AudioManager::close() even if
> initialize never started.

Done.

[DaleCurtis, 2016-06-21 23:48:42]

lgtm though InitializeIfNeeded() is a bit misleading.

[no sievers, 2016-06-21 23:57:22]

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

https://codereview.chromium.org/2077983003/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_process_host_impl.cc:609:
media::AudioManager::StartHangMonitor(
Doesn't this blow up if being called repeatedly?

Maybe just needs a 'if (!BrowserMainLoop::GetInstance()->audio_manager())'?

[qinmin, 2016-06-22 00:15:56]

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

https://codereview.chromium.org/2077983003/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_process_host_impl.cc:609:
media::AudioManager::StartHangMonitor(
On 2016/06/21 23:57:22, sievers wrote:
> Doesn't this blow up if being called repeatedly?
> 
> Maybe just needs a 'if (!BrowserMainLoop::GetInstance()->audio_manager())'?

That doesn't work in ChromeOS case though since audio_manager() is already
created before renderer process are created.
I changed the AudioManagerHelper::StartHangTimer() to abort early if this is
already called.

[no sievers, 2016-06-22 00:31:18]

lgtm

https://codereview.chromium.org/2077983003/diff/100001/content/browser/render...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2077983003/diff/100001/content/browser/render...
content/browser/renderer_host/render_process_host_impl.cc:608: // necessary or
recommended.
nit: Can you put a comment that we intentionally defer watchdog creation until
we start a renderer?

Maybe it should also be called 'Start..IfNecessary()' or something?

[qinmin, 2016-06-22 18:57:19]

Patchset #6 (id:120001) has been deleted

[qinmin, 2016-06-22 21:00:02]

Patchset #6 (id:140001) has been deleted

[qinmin, 2016-06-22 22:21:47]

Patchset #6 (id:160001) has been deleted

[qinmin, 2016-06-23 21:44:29]

Patchset #6 (id:180001) has been deleted

[qinmin, 2016-06-24 18:49:52]

Patchset #6 (id:200001) has been deleted

[qinmin, 2016-06-24 22:48:00]

Patchset #6 (id:220001) has been deleted

[qinmin, 2016-06-25 00:00:55]

Patchset #6 (id:240001) has been deleted

[qinmin, 2016-06-27 21:01:31]

On 2016/06/22 00:31:18, sievers wrote:
> lgtm
> 
>
https://codereview.chromium.org/2077983003/diff/100001/content/browser/render...
> File content/browser/renderer_host/render_process_host_impl.cc (right):
> 
>
https://codereview.chromium.org/2077983003/diff/100001/content/browser/render...
> content/browser/renderer_host/render_process_host_impl.cc:608: // necessary or
> recommended.
> nit: Can you put a comment that we intentionally defer watchdog creation until
> we start a renderer?
> 
> Maybe it should also be called 'Start..IfNecessary()' or something?

[qinmin, 2016-06-27 21:01:41]

https://codereview.chromium.org/2077983003/diff/100001/content/browser/render...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2077983003/diff/100001/content/browser/render...
content/browser/renderer_host/render_process_host_impl.cc:608: // necessary or
recommended.
On 2016/06/22 00:31:18, sievers wrote:
> nit: Can you put a comment that we intentionally defer watchdog creation until
> we start a renderer?
> 
> Maybe it should also be called 'Start..IfNecessary()' or something?

Done.

[qinmin, 2016-06-27 21:03:34]

The CQ bit was checked by qinmin@chromium.org

[qinmin, 2016-06-27 21:03:34]

The patchset sent to the CQ was uploaded after l-g-t-m from
dalecurtis@chromium.org, sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2077983003/#ps260001
(title: "fix test and lazy init jobj")

[commit-bot: I haz the power, 2016-06-27 21:04:37]

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, 2016-06-27 22:18:16]

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

[commit-bot: I haz the power, 2016-06-27 22:18:17]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[qinmin, 2016-06-27 22:31:41]

The CQ bit was checked by qinmin@chromium.org

[commit-bot: I haz the power, 2016-06-27 22:33:23]

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, 2016-06-27 23:46:27]

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

[commit-bot: I haz the power, 2016-06-27 23:46:29]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[qinmin, 2016-06-29 21:16:00]

Patchset #7 (id:280001) has been deleted

[qinmin, 2016-06-30 17:22:13]

Patchset #7 (id:300001) has been deleted

[qinmin, 2016-07-06 17:05:18]

The CQ bit was checked by qinmin@chromium.org

[qinmin, 2016-07-06 17:05:18]

The patchset sent to the CQ was uploaded after l-g-t-m from
dalecurtis@chromium.org, sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2077983003/#ps320001
(title: "fix MediaSessionTest")

[commit-bot: I haz the power, 2016-07-06 17:05:44]

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, 2016-07-06 17:13:42]

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

[commit-bot: I haz the power, 2016-07-06 17:13:44]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[qinmin, 2016-07-06 17:25:55]

Patchset #7 (id:320001) has been deleted

[qinmin, 2016-07-06 17:26:14]

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

[commit-bot: I haz the power, 2016-07-06 17:27:06]

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

[qinmin, 2016-07-06 18:24:47]

The CQ bit was unchecked by qinmin@chromium.org

[qinmin, 2016-07-06 18:24:53]

The CQ bit was checked by qinmin@chromium.org

[qinmin, 2016-07-06 18:24:53]

The patchset sent to the CQ was uploaded after l-g-t-m from
dalecurtis@chromium.org, sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2077983003/#ps340001
(title: "fix MediaSessionTest")

[commit-bot: I haz the power, 2016-07-06 18:25:29]

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, 2016-07-06 21:21:01]

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

[commit-bot: I haz the power, 2016-07-06 21:21:03]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[qinmin, 2016-07-06 21:25:24]

The CQ bit was checked by qinmin@chromium.org

[commit-bot: I haz the power, 2016-07-06 21:25:52]

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, 2016-07-07 00:33:52]

Description was changed from

==========
Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager takes about 10KB of memory.
This is only needed when the first renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479
==========

to

==========
Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager takes about 10KB of memory.
This is only needed when the first renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479
==========

[commit-bot: I haz the power, 2016-07-07 00:33:54]

Committed patchset #7 (id:340001)

[commit-bot: I haz the power, 2016-07-07 00:34:11]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-07 00:37:27]

Description was changed from

==========
Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager takes about 10KB of memory.
This is only needed when the first renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479
==========

to

==========
Intiialize AudioManager and related class lazily

AudioManager is created when browser process is created.
However, for background download resumption, we don't need AudioManager
for download to resume.
Creating the AudioManager takes about 10KB of memory.
This is only needed when the first renderer is created.
This CL delays AudioManager creation until it is first referenced.
This also involves some other classes that depends on AudioManager.

BUG=620479

Committed: https://crrev.com/c8569a7cd8c3cb6f9cd22467e084860721ceadd7
Cr-Commit-Position: refs/heads/master@{#404014}
==========

[commit-bot: I haz the power, 2016-07-07 00:37:29]

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