Limit OnData() callbacks to every 5ms for mac audio input.

Limit OnData() callbacks to every 5ms for mac audio input.

OSX doesn't like the audio data being retimed and we apparently can
not have Flash use a larger buffer size...  So this hack ensures each
OnData() call has time to deliver audio data to the renderer without
it being smashed by the next call.  5ms was chosen since we use the
same value for a similar hack in AlsaPcmOutputStream.

This is not ideal and instead Pepper input clients should be using at
least a 4k buffer on OSX until switched to the low latency pipeline.

There's no guarantee that the audio input stream won't drop out at a
much later time, but in local testing it's much greater than the 1.5
minutes to dropout we have now.

BUG=157613, 168859
TEST=audio input doesn't drop out. longevity testing ongoing.


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

[DaleCurtis, 2013-01-23 19:28:45]

Will back-merge to M25, M24.

[scherkus (not reviewing), 2013-01-24 00:30:48]

this makes me sad and wonder whether there's a way to prevent clobbering somehow
-- I'll rubber stamp LGTM this assuming your soak tests last much, much longer
than the 30 mins you've quoted so far (hours? overnight?)


OOC did you track down why it would break in 1.5 minutes? The fact that
calculations were driven by the value of audio_buffer->mAudioDataByteSize makes
me wonder whether we were Sleep()'ing for a long time.

[DaleCurtis, 2013-01-24 01:38:14]

On 2013/01/24 00:30:48, scherkus wrote:
> this makes me sad and wonder whether there's a way to prevent clobbering
somehow
> -- I'll rubber stamp LGTM this assuming your soak tests last much, much longer
> than the 30 mins you've quoted so far (hours? overnight?)
> 
> 
> OOC did you track down why it would break in 1.5 minutes? The fact that
> calculations were driven by the value of audio_buffer->mAudioDataByteSize
makes
> me wonder whether we were Sleep()'ing for a long time.

Yeah, I'm sad too. As mentioned the ideal fix (for high latency usage) is for
Pepper clients to use a 4k buffer which is equivalent to the buffer size used by
OSX for 44kHz. Since the buffer sizes are the same, callbacks are then delivered
every ~90ms as expected.  Another solution would be true blocking shared memory,
which is what we're attempting to emulate here.

The soak test has been running for > 4.5 hours now without issue. 

The problem is internal to OSX. I don't know what the issue is there. OSX
continues to issue callbacks providing the 2k buffers and we sleep the
appropriate ~45ms, but the buffers returned are empty.

[commit-bot: I haz the power, 2013-01-24 02:10:18]

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

[commit-bot: I haz the power, 2013-01-24 04:49:49]

Change committed as 178517