Reduce amount of power measurements for input audio

Reduce amount of power measurements for input audio.

Goal is to:

1) Reduce amount of log overhead for WebRTC clients;
2) Reduce risk for false-alarm for "no data" on initial short streams.

BUG=405449
Committed: https://crrev.com/ec12b08b4ec896c7b78f1c3a0ef2b330bff837fc
Cr-Commit-Position: refs/heads/master@{#293717}

[henrika (OOO until Aug 14), 2014-09-08 09:02:06]

henrika@chromium.org changed reviewers:
+ grunell@chromium.org, xians@chromium.org

[henrika (OOO until Aug 14), 2014-09-08 09:03:31]

We can still add UMA for initial streams which will be closed and no longer used
during a WebRTC call. These "dead streams" can be up to 9-10 seconds (found on
Mac) when it takes a long time to set up the call.

[Henrik Grunell, 2014-09-08 10:57:24]

https://codereview.chromium.org/551763003/diff/1/media/audio/audio_input_cont...
File media/audio/audio_input_controller.cc (right):

https://codereview.chromium.org/551763003/diff/1/media/audio/audio_input_cont...
media/audio/audio_input_controller.cc:48: const int
kPowerMonitorLogIntervalSeconds = 15;
Would it make sense to have 15 seconds to the first check, then 5 seconds
interval after that? Or is 15 seconds sample rate good enough? There's a higher
risk of false alarms for short sessions, e.g. for a 29 seconds call we'll only
have 1 sample. If it happens to be silent at that point we have a false alarm.
Maybe those cases are so few we don't have to bother.

[no longer working on chromium, 2014-09-08 11:05:58]

On 2014/09/08 09:03:31, henrika wrote:
> We can still add UMA for initial streams which will be closed and no longer
used
> during a WebRTC call. These "dead streams" can be up to 9-10 seconds (found on
> Mac) when it takes a long time to set up the call.

:) It is bug if the stream takes 9-10 seconds to set up. Should we file a bug
and create uma to track the setup time?

[Henrik Grunell, 2014-09-08 11:17:48]

On 2014/09/08 11:05:58, xians1 wrote:
> On 2014/09/08 09:03:31, henrika wrote:
> > We can still add UMA for initial streams which will be closed and no longer
> used
> > during a WebRTC call. These "dead streams" can be up to 9-10 seconds (found
on
> > Mac) when it takes a long time to set up the call.
> 
> :) It is bug if the stream takes 9-10 seconds to set up. Should we file a bug
> and create uma to track the setup time?

If it's a bug - file a bug. :) Is it a bug in Chrome or the OS?
I think the setup time would be good to have.

[henrika (OOO until Aug 14), 2014-09-08 11:22:20]

It might not be the actual stream that takes so long time to set up, it is a
combination of things in Hangout which can take so long time to join. I don't
think this is the correct level so log such an issue.

grunell: why do you want to log 30 times per minute? It will create rather large
log files and I am not sure what it adds.

[henrika (OOO until Aug 14), 2014-09-08 11:25:21]

But sure, I can add logging of total life time of an audio input stream. Would
like to do that in a separate CL if needed.

[Henrik Grunell, 2014-09-08 11:26:28]

On 2014/09/08 11:22:20, henrika wrote:
> It might not be the actual stream that takes so long time to set up, it is a
> combination of things in Hangout which can take so long time to join. I don't
> think this is the correct level so log such an issue.
> 
> grunell: why do you want to log 30 times per minute? It will create rather
large
> log files and I am not sure what it adds.

Right, it's very good to reduce log output. I was actually thinking of the UMA
stats that's reported once in the end. Maybe it's a bit to complex to be worth
satisfying both.

LGTM.

[henrika (OOO until Aug 14), 2014-09-08 11:54:31]

xians: I have already added stats for input stream duration. See
Media.InputStreamDuration ;-)

[no longer working on chromium, 2014-09-08 12:09:36]

On 2014/09/08 11:54:31, henrika wrote:
> xians: I have already added stats for input stream duration. See
> Media.InputStreamDuration ;-)

thanks. 

lgtm

[henrika (OOO until Aug 14), 2014-09-08 12:33:49]

The CQ bit was checked by henrika@chromium.org

[commit-bot: I haz the power, 2014-09-08 12:37:26]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/henrika@chromium.org/551763003/1

[commit-bot: I haz the power, 2014-09-08 14:07:20]

Committed patchset #1 (id:1) as 125bd7abe49067702e655fb65f1b2c3111ed690d

[commit-bot: I haz the power, 2014-09-10 03:46:01]

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