Fixes audio issue on Mac for USB headsets

Fixes audio issue on Mac for USB headsets where kAudioUnitErr_TooManyFramesToProcess can be returned for a few frames at startup.

BUG=466954, 466046
TEST=Manual tests of WebRTC clients and different USB headsets.

Committed: https://crrev.com/956d30cb23b16161170a91d5fcaa316bc0b0eaab
Cr-Commit-Position: refs/heads/master@{#320921}

[henrika (OOO until Aug 14), 2015-03-17 09:38:36]

henrika@chromium.org changed reviewers:
+ dalecurtis@chromium.org

[henrika (OOO until Aug 14), 2015-03-17 09:45:59]

Dale, I know that you recently added usage of HandleError and improved how the
error was handled. However, it seems like stopping the input stream can be too
strict in some corner cases where we see kAudioUnitErr_TooManyFramesToProcess
for one or two initial callbacks and then never again. It can cause input audio
to break in combination with some USB headsets and this patch is an attempt to
let these error messages pass to keep the stream alive.

We have seen several similar reports related to "no audio with USN headset on
Mac" and this patch seems to resolve these issues. I would like to try it out on
Canary for more feedback.

Thanks.

[tommi (sloooow) - chröme, 2015-03-17 15:34:11]

tommi@chromium.org changed reviewers:
+ tommi@chromium.org

[tommi (sloooow) - chröme, 2015-03-17 15:34:11]

lgtm - since Dale is currently out.

[henrika (OOO until Aug 14), 2015-03-17 15:36:51]

The CQ bit was checked by henrika@chromium.org

[commit-bot: I haz the power, 2015-03-17 15:37:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1017683002/1

[henrika (OOO until Aug 14), 2015-03-17 15:40:35]

Landing since we have many users who want to try this out in Canary.

[commit-bot: I haz the power, 2015-03-17 15:40:50]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-17 15:41:21]

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

[DaleCurtis, 2015-03-18 17:01:26]

You'll need to watch this very closely. The bug this fixed is a system hang
which didn't show up in automated crash reports well. In general it lgtm, but I
worry that without some sort of error threshold it will send the system into a
spinloop.

[DaleCurtis, 2015-03-18 22:09:06]

https://codereview.chromium.org/1017683002/diff/1/media/audio/mac/audio_low_l...
File media/audio/mac/audio_low_latency_input_mac.cc (right):

https://codereview.chromium.org/1017683002/diff/1/media/audio/mac/audio_low_l...
media/audio/mac/audio_low_latency_input_mac.cc:502: // but only for a few
initial frames at startup and then then the stream
Since you explicitly mention that this returns to normal shortly, can you add a
backoff count which fires an error once a threshold is hit?

[no longer working on chromium, 2015-03-18 22:15:00]

xians@chromium.org changed reviewers:
+ xians@chromium.org

[no longer working on chromium, 2015-03-18 22:15:01]

https://codereview.chromium.org/1017683002/diff/1/media/audio/mac/audio_low_l...
File media/audio/mac/audio_low_latency_input_mac.cc (right):

https://codereview.chromium.org/1017683002/diff/1/media/audio/mac/audio_low_l...
media/audio/mac/audio_low_latency_input_mac.cc:502: // but only for a few
initial frames at startup and then then the stream
On 2015/03/18 22:09:06, DaleCurtis wrote:
> Since you explicitly mention that this returns to normal shortly, can you add
a
> backoff count which fires an error once a threshold is hit?

It is a bit hard to define the threshold since it depends on the device, sort of
timing things related to ramp change.

How about adding a uma stat to get some understanding?

[henrika (OOO until Aug 14), 2015-03-19 08:59:48]

Thanks for your feedback. We have received positive feedback that the current
fix resolves issues that are rather common in e.g. Hangout and other WebRTC
clients. I do realize the risk but I've been asked to merge this fix and don't
know if I should do more changes now or wait until after merging.

Let me upload a proposal and continue the discussion there instead.