Don't switch to fake audio output until stream open fails.

Don't switch to fake audio output until stream open fails.

Moves the selection of fake audio output from AudioManagerBase
into AudioOutputResampler.  Now instead of silently switching to
the fake audio path, we'll fall back into it when all else fails.

This works around issues with the HasAudioOutputDevices() code
and ensures we don't leave the user in a broken state when audio
creation fails.

The downside here is that instead of immediately switching to the
fake audio path during create stream, we now cycle through the
creation of audio streams.

BUG=158478, 162953
TEST=Manual, fake audio path takes over when all Open() calls fail.


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

[DaleCurtis, 2013-02-13 23:45:37]

WDYT? I'm not sure about this, but I do think it'll provide a better user
experience in the rare cases we fail to open any real stream. It's also a bit
cleaner than silently switching a normal stream to a fake stream in
AudioManager. The cost is two failed Open() calls vs an immediate success.

Some of the AudioOutputResampler unit tests still need cleanup, I'll fix them if
we decide to move forward with this change.

[scherkus (not reviewing), 2013-02-14 00:56:03]

seems like a good thing to do :)

OOC any rough #s on how long does it take to cycle through the creation code?

[DaleCurtis, 2013-02-15 01:42:14]

No measurable overhead on Linux, Windows goes from 10ms -> 40ms.  Any connection
for the same parameters afterward is instant though.

The one danger here is users with systems with valid hardware audio output
parameters yet HasAudioOutputDevices() returns false.  With device change
support if a new device comes in we'll recreate with the output device
parameters and get a connection.

Now however, since we've fallen back to the fake stream, we'll route all future
streams to the fake until browser restart or a hardware output parameters
change.

On Linux, ChromeOS, and Mac we fall back never, never, and O(10) times
respectively.  On Windows we fall back O(100000) times, likely due to broken
WaveOut.  Thus Windows is really the only platform to worry about here and
historical data shows we get invalid audio parameters in this case.  Which
prevents AudioOutputResampler from ever being created.

All of that is a roundabout way of saying I don't think they'll actually be a
danger.  PTAL.  I've fixed the unit test.

[scherkus (not reviewing), 2013-02-15 18:43:37]

lgtm

https://codereview.chromium.org/12261027/diff/4/media/audio/audio_manager_bas...
File media/audio/audio_manager_base.cc (left):

https://codereview.chromium.org/12261027/diff/4/media/audio/audio_manager_bas...
media/audio/audio_manager_base.cc:111: !HasAudioOutputDevices();
FYI this appeared to be the only production code use of HasAudioOutputDevices()
-- the rest were unit tests

now that we have proper fallback support, technically we could remove the check
from tests and they'd run again a fake device. not sure how useful that is
though.

[DaleCurtis, 2013-02-15 18:51:39]

https://codereview.chromium.org/12261027/diff/4/media/audio/audio_manager_bas...
File media/audio/audio_manager_base.cc (left):

https://codereview.chromium.org/12261027/diff/4/media/audio/audio_manager_bas...
media/audio/audio_manager_base.cc:111: !HasAudioOutputDevices();
On 2013/02/15 18:43:37, scherkus wrote:
> FYI this appeared to be the only production code use of
HasAudioOutputDevices()
> -- the rest were unit tests
> 
> now that we have proper fallback support, technically we could remove the
check
> from tests and they'd run again a fake device. not sure how useful that is
> though.

Yeah, that's why I was looking at this originally. I think we can remove the
method, but we definitely can't remove HasAudioInputDevices(), so I'm wondering
if it it's best to keep both for symmetry. I believe most implementations use a
common "find devices" method and vary the input vs output parameter.

[commit-bot: I haz the power, 2013-02-15 18:52:28]

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

[commit-bot: I haz the power, 2013-02-15 22:27:59]

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

[commit-bot: I haz the power, 2013-02-16 18:25:55]

Change committed as 182989