An interesting detail is that we always attempt a player restart when getting a media element error, so this would be happening twice in a row. Messing with logging now to find out what proportion of restarts happen due to audio (as opposed to what proportion of second-in-a-row failures, which is what you've seen before).

strobe: Did you end up finding that data?

Given the ability of client side JS to recover from non-device-change related errors it seems reasonable to defer, so I put that up here https://chromium-review.googlesource.com/c/602596

So do you propose in case of error to basically start diverting to a fake stream and to wait for a device change event with a timeout? Sounds like a source of new fancy bugs :)

"just deferring errors for a couple seconds to ensure a device change isn't happening" for video playback will result in a lag between audio and video, won't it?

Another idea (brain-storming) is to signal a "pause" error first - renderer can pause playback on it - and then if device switch (any other type of recovery in general) has not happened within a timeout then signal a "fatal" error.

>>  will result in a lag between audio and video, won't it?
Hmm, actually deferring should not affect audio/video sync more than device change does.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/974674dd40bbb79bf9849f1ccdbfb98c9826b69b

commit 974674dd40bbb79bf9849f1ccdbfb98c9826b69b
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Aug 11 00:06:55 2017

Defer AOC::OnError() to avoid spurious device change errors.

There are a few devices out there that end up delivering an error
through the AudioOutputStream::AudioSourceCallback interface
_before_ a device change starts. These errors are transient and
we expect playback on the new device to work correctly.

To workaround this defer all errors for 1 second to ensure there
are no upcoming device changes which will resolve the error. We
expect device changes to take a few hundred milliseconds so the
1 second value is chosen arbitrarily to exceed that.

We could also consider switching out streams with errors with fake
streams, but in the event of transient failures this would prevent
the client javascript from detecting the error and attempting a
player restart. The defer approach allows this to still happen.

This change expands the existing lock+bool we have for ignoring
errors _during_ a stop & close to using a WeakPtr and delayed
task to ignore errors during and immediately before the device
change occurs.

BUG= 751780 , 746749 
TEST=new unittest.

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I54dad90389dd0fda3d056791dffd1d8127a0d96c
Reviewed-on: https://chromium-review.googlesource.com/602596
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Max Morin <maxmorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493607}
[modify] https://crrev.com/974674dd40bbb79bf9849f1ccdbfb98c9826b69b/content/browser/renderer_host/media/audio_output_delegate_impl_unittest.cc
[modify] https://crrev.com/974674dd40bbb79bf9849f1ccdbfb98c9826b69b/media/audio/audio_output_controller.cc
[modify] https://crrev.com/974674dd40bbb79bf9849f1ccdbfb98c9826b69b/media/audio/audio_output_controller.h
[modify] https://crrev.com/974674dd40bbb79bf9849f1ccdbfb98c9826b69b/media/audio/audio_output_controller_unittest.cc

Do we know if this a regression?

I'm not sure, but I don't think so. We've seen issues like this in the past with driver updates.

It seems to have about a 0.05% change in audio renderer errors, which is lower than in recent history too.

Looks like there's another case (IAudioClient/IAudioRenderClient) dying after a Stop() that can get us into a bad state. Per Microsoft we should attempt recovery of the clients during Start().

Whoops, reopened the wrong bug; will just file a new one;  issue 803691 .