Which OS?

Windows 10 build 15063

Is this usb or jack based headphone? Didn't reproduce with jack based headphone for me.

Am using a head phone Jack. To make sure it is still reproducible, I just tested it and it is still reproducible.

Thanks, will try on some other machines and loop in a few folk who might be able to test as well.

Which sound card do you have?

I've tried a few machines both at home and work with a variety of USB and jack based headphones and things are working as expected on YouTube and other sites.

Can you grab the contents of the "Audio" tab in chrome://media-internals when the device is working and when it isn't?

I have Cirrus Logic CS4208 (AB 94))

Deleted: Before.PNG 65.3 KB

	Before.PNG 65.3 KB View Download

Deleted: After.PNG 68.9 KB

	After.PNG 68.9 KB View Download

Sorry I need to see the "audio" tab, not the "players" tab. 

Thanks definitely we're sending an audio renderer error for some reason. If you're comfortable doing so, you can try installing https://github.com/google/sawbuck/releases and then triggering the failure (make sure to start log capture in sawbuck). This should provide us with more details on what might be going wrong.

give to dale to follow up.

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

@tummalasujith: Can you try Chrome Canary and see if the issue is resolved for you? Stats show a ~0.05% reduction in audio renderer errors after this change.

Tentatively marking as fixed for m62