Provide a default return value for mock_audio_device_.TimeUntilNextProcess.

Provide a default return value for mock_audio_device_.TimeUntilNextProcess.
By default the return value will be 0, which if we hit, could cause busy loops.

BUG=webrtc:7187
Review-Url: https://codereview.webrtc.org/2750503002
Cr-Commit-Position: refs/heads/master@{#17213}
Committed: https://chromium.googlesource.com/external/webrtc/+/8eb0751b2e53e43b2eb0bdb521114f22e5754ac4

[tommi, 2017-03-13 11:02:14]

tommi@webrtc.org changed reviewers:
+ ossu@webrtc.org

[tommi, 2017-03-13 11:02:55]

Description was changed from

==========
Provide a default return value for mock_audio_device_.TimeUntilNextProcess.
By default the return value will be 0, which if we hit, could cause busy loops.

BUG=none
==========

to

==========
Provide a default return value for mock_audio_device_.TimeUntilNextProcess.
By default the return value will be 0, which if we hit, could cause busy loops.

BUG=webrtc:7187
==========

[ossu, 2017-03-13 14:33:32]

So, do we hit this or not?
If we do, waiting a whole second seems steep, but I may not understand its use
fully. I'm thinking in the case this delay gets introduced a handful of times in
a test or two, which suddenly run five seconds slower or something.

[tommi, 2017-03-13 14:36:56]

On 2017/03/13 14:33:32, ossu wrote:
> So, do we hit this or not?
> If we do, waiting a whole second seems steep, but I may not understand its use
> fully. I'm thinking in the case this delay gets introduced a handful of times
in
> a test or two, which suddenly run five seconds slower or something.

I'm not aware of us hitting it.  I picked a deliberately high value to make it
obvious if we do hit it.
The delay itself doesn't translate to a wait, but it would mean that an expected
call to Process() won't happen until a whole second has passed and that should
be a long enough period to make a test that doesn't set expectations correctly,
to fail.

[ossu, 2017-03-13 14:44:30]

On 2017/03/13 14:36:56, tommi (webrtc) wrote:
> On 2017/03/13 14:33:32, ossu wrote:
> > So, do we hit this or not?
> > If we do, waiting a whole second seems steep, but I may not understand its
use
> > fully. I'm thinking in the case this delay gets introduced a handful of
times
> in
> > a test or two, which suddenly run five seconds slower or something.
> 
> I'm not aware of us hitting it.  I picked a deliberately high value to make it
> obvious if we do hit it.
> The delay itself doesn't translate to a wait, but it would mean that an
expected
> call to Process() won't happen until a whole second has passed and that should
> be a long enough period to make a test that doesn't set expectations
correctly,
> to fail.

Alright, seems reasonable.
LGTM

[tommi, 2017-03-13 14:45:37]

The CQ bit was checked by tommi@webrtc.org

[commit-bot: I haz the power, 2017-03-13 14:45:48]

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

[commit-bot: I haz the power, 2017-03-13 15:23:36]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1489416337322390, "parent_rev":
"96feb2ac1c2f0b3a477807db7a11d10eb5a138bd", "commit_rev":
"8eb0751b2e53e43b2eb0bdb521114f22e5754ac4"}

[commit-bot: I haz the power, 2017-03-13 15:23:38]

Description was changed from

==========
Provide a default return value for mock_audio_device_.TimeUntilNextProcess.
By default the return value will be 0, which if we hit, could cause busy loops.

BUG=webrtc:7187
==========

to

==========
Provide a default return value for mock_audio_device_.TimeUntilNextProcess.
By default the return value will be 0, which if we hit, could cause busy loops.

BUG=webrtc:7187

Review-Url: https://codereview.webrtc.org/2750503002
Cr-Commit-Position: refs/heads/master@{#17213}
Committed:
https://chromium.googlesource.com/external/webrtc/+/8eb0751b2e53e43b2eb0bdb52...
==========

[commit-bot: I haz the power, 2017-03-13 15:23:39]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/webrtc/+/8eb0751b2e53e43b2eb0bdb52...