[scheduler] Teach scheduler about audio state

content/common/page_messages.h

Index: content/common/page_messages.h
diff --git a/content/common/page_messages.h b/content/common/page_messages.h
index 6b988a352d485269c289de40f0826dac8f673600..6d81f3f965eaff01abb2f49c8d88bd3b60ac1378 100644
--- a/content/common/page_messages.h
+++ b/content/common/page_messages.h
@@ -43,6 +43,8 @@ IPC_MESSAGE_ROUTED2(PageMsg_SetHistoryOffsetAndLength,
                     int /* history_offset */,
                     int /* history_length */)
 
+IPC_MESSAGE_ROUTED1(PageMsg_AudioStateChanged, bool /* is_audio_playing */)

[miu, 2016/11/15 22:04:04]

OOC, why are we doing this whole "round about" approach: send sound to the
browser process, then have it do audible detection (takes time), and finally
send the renderer back a message to determine whether it should disable
throttling?

Instead, it seems like anything that causes audio to be generated should
directly call DisableThrottling() (e.g., from HTMLMediaElement.cpp, the WebAudio
modules, etc.). Then, correct behavior would not be dependent on the browser
process.

[altimin, 2016/11/16 12:22:32]

Because we do not want to disable throttling when page is not audible. Also this
approach makes easy to explain when we avoid throttling -- the rules are the
same as for displaying sound notification in browser UI. (Also controlling
scheduler settings is not uncommon - for example, foreground/background page
stage is forwarded to the scheduler via browser process).

If you have further questions, let's continue discussion in
crrev.com/2496173003.

+
 // -----------------------------------------------------------------------------
 // Messages sent from the renderer to the browser.