Privitize WaitTillDataReady() and DataReady().

Privitize WaitTillDataReady() and DataReady().

There's no reason for these to be called all over the code base when we
know the limited circumstances under which they must be called.  Making
these private allows for a considerable cleanup of code.

The one sketchy part about this CL is removing PollAndStartIfDataReady()
for OSX.  I believe stream startup times are long enough that data will
always be ready though.  If this is not the case and our OSX stats for
DataReady() plummet, we can find a simpler solution then polling.

This change also fixes inaccuracy with the UMA histogram since previously
we were reporting DataReady() after WaitTilDataReady() had already been
called.

BUG=none
TEST=audio plays w/o glitching on mac, win, linux.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204172

[DaleCurtis, 2013-05-29 23:00:12]

+justinlin for the virtual_audio_output_stream.cc change.

[justinlin, 2013-05-30 18:06:05]

On 2013/05/29 23:00:12, DaleCurtis wrote:
> +justinlin for the virtual_audio_output_stream.cc change.

lgtm for virtual_audio_output_stream.cc

[henrika (OOO until Aug 14), 2013-06-03 07:57:12]

LGTM w/ nits.

However, it is not 100% clear to me that the removal of kStarting in the AOC is
a consequence of privitizing WaitTillDataReady() and DataReady().

In any case, the code feels much more readable now. Thanks.

[henrika (OOO until Aug 14), 2013-06-03 07:57:17]

https://codereview.chromium.org/16103007/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/media/audio_sync_reader.cc (right):

https://codereview.chromium.org/16103007/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/media/audio_sync_reader.cc:171: const
base::TimeDelta kMaxWait = base::TimeDelta::FromMilliseconds(20);
Is it OK to use hard coded values here or should we break out kWait-consts with
a comment for each?

https://codereview.chromium.org/16103007/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/media/audio_sync_reader.cc:173: // Sleep(0) on
windows lets the other threads run.
nit, Windows

https://codereview.chromium.org/16103007/diff/2001/media/audio/audio_io.h
File media/audio/audio_io.h (left):

https://codereview.chromium.org/16103007/diff/2001/media/audio/audio_io.h#old...
media/audio/audio_io.h:78: virtual void WaitTillDataReady() {}
Thanks for removing this one ;-)

https://codereview.chromium.org/16103007/diff/2001/media/audio/win/waveout_ou...
File media/audio/win/waveout_output_win.cc (left):

https://codereview.chromium.org/16103007/diff/2001/media/audio/win/waveout_ou...
media/audio/win/waveout_output_win.cc:209: if (ix != 0)
Great that you was able to get rid of this one.

[DaleCurtis, 2013-06-04 00:35:41]

crogers: Any other comments?

https://codereview.chromium.org/16103007/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/media/audio_sync_reader.cc (right):

https://codereview.chromium.org/16103007/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/media/audio_sync_reader.cc:171: const
base::TimeDelta kMaxWait = base::TimeDelta::FromMilliseconds(20);
On 2013/06/03 07:57:18, henrika wrote:
> Is it OK to use hard coded values here or should we break out kWait-consts
with
> a comment for each?

I think it's okay as is. davemoore@ just cleaned this up in a previous CL. I'm
only moving things around.

https://codereview.chromium.org/16103007/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/media/audio_sync_reader.cc:173: // Sleep(0) on
windows lets the other threads run.
On 2013/06/03 07:57:18, henrika wrote:
> nit, Windows

Done.

[Chris Rogers, 2013-06-04 19:25:18]

Thanks Dale, definitely an improvement! lgtm

[commit-bot: I haz the power, 2013-06-04 19:54:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dalecurtis@chromium.org/16103007/16001

[commit-bot: I haz the power, 2013-06-05 06:12:37]

Change committed as 204172