Purge AudioOutputDispatcher after close delay if no proxies exist.

Purge AudioOutputDispatcher after close delay if no proxies exist.

This prevents transient audio creation errors from cumulatively
breaking audio output by blackholing everything to a fake audio
stream after fallback attempts are exhausted.

BUG=453560
TEST=new unittest, manual testing.

Committed: https://crrev.com/c85184da42d043995203dbba777f08af00181d65
Cr-Commit-Position: refs/heads/master@{#314910}

[DaleCurtis, 2015-02-05 03:15:08]

Patchset #1 (id:1) has been deleted

[DaleCurtis, 2015-02-05 18:44:27]

Patchset #1 (id:20001) has been deleted

[DaleCurtis, 2015-02-05 18:44:52]

dalecurtis@chromium.org changed reviewers:
+ dgreid@chromium.org, miu@chromium.org

[DaleCurtis, 2015-02-05 18:50:58]

Patchset #1 (id:40001) has been deleted

[DaleCurtis, 2015-02-05 18:52:25]

Hey guys, please review. miu@ sorry to throw you under the bus here, but I think
you're only person in recent history besides me to look at this code :)

[miu, 2015-02-05 19:58:54]

This all lgtm, but should the close delay be very small (or zero?) for fake
streams?  Is there any reason the system should be "caching" fake streams in the
first place?  Maybe AudioManager should not use any of the caching
infrastructure when it creates a fake stream as a fallback?

[DaleCurtis, 2015-02-05 20:37:55]

The fake stream is created internally to the AudioOutputResampler; the
AudioManager doesn't do any fallback, it's all handled within
AudioOutputResampler.  AudioManager will only create a fake if invalid output
parameters are provided, which should be rare (some Windows systems return a
sample rate of zero!)

Repeated fallthrough to the fake audio path can be expensive, so I think it
should be rate limited by time. I'm open to using a value < 5 seconds (the
current close delay) though.

[miu, 2015-02-05 20:47:41]

On 2015/02/05 20:37:55, DaleCurtis wrote:
> Repeated fallthrough to the fake audio path can be expensive, so I think it
> should be rate limited by time. I'm open to using a value < 5 seconds (the
> current close delay) though.

Is the 5-second close delay enough to alleviate the CrOS startup race issue?

Maybe not this change, but perhaps the AudioOutputStream impl for CrOS should
provide its own internal "fake" that automatically switches to the correct code
path once the CrOS sound system is up?  Not sure how much work that'd be, or if
it's feasible in the current design.

[DaleCurtis, 2015-02-05 20:57:17]

Having recovery at all should be enough to fix the problem provided something
isn't hammering the audio device with constant stream creation.

Yeah, we could also do this in AudioManagerCras if it can detect that Cras isn't
ready yet. It could then return fake streams pre-startup. I don't know if media/
can depend on the code necessary to check this though. dgreid@, any tips?

[dgreid, 2015-02-05 21:42:42]

the audio manager, well cras_output directly will see the add stream call fail
with an error that indicates it can't communicate with the server. So there is
information at that level to do this.  It would really be better to
deterministically not start an audio stream before it's ready.  Not sure how to
plumb that through though

[dgreid, 2015-02-05 23:13:43]

lgtm

[DaleCurtis, 2015-02-05 23:15:24]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2015-02-05 23:16:02]

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

[commit-bot: I haz the power, 2015-02-05 23:20:13]

Committed patchset #1 (id:60001)

[commit-bot: I haz the power, 2015-02-05 23:22:22]

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