New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 160920 link

Starred by 108 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Audio stops working on OSX and requires a browser restart to fix.

Reported by leanne...@gmail.com, Nov 14 2012

Issue description

Chrome Version       : 23.0.1271.64 (Official Build 165188) m
URLs (if applicable) : http://www.youtube.com
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
       IE 7/8/9: OK

What steps will reproduce the problem?
1. Playing a video on YouTube
2.
3.

What is the expected result?
Expected a full audio-video functionality.

What happens instead?
No audio was heard but the video was fine.

Please provide any additional information below. Attach a screenshot if
possible.
 
Showing comments 48 - 147 of 147 Older
Confirm it doesn't only happen in SSD macs.  Mine is a 2010 model without SSD 
If you're tech savvy and able to reproduce this issue consistently and would like to help track it down... I've uploaded an instrumented build for download here:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-test-3.tar.bz2

After extracting, run it like so:

./Chromium.app/Contents/MacOS/Chromium --enable-logging --user-data-dir=/tmp/.data --disk-cache-dir=/tmp/.cache

There should be logging to the console as well as logs in

/tmp/.data/chrome_debug.log

If you could use this build until you hit the issue that'd be awesome.  Once you hit the issue please try starting a trace (via chrome://tracing) and then navigate to

http://commondatastorage.googleapis.com/dalecurtis-shared/buck2.webm

Let it run for a couple seconds and then stop and save the trace.  Please upload the chrome_debug.log and trace file afterward.

This build includes some experimental work as well, so if you can't reproduce the issue with this build, please check the "/tmp/.data/chrome_debug.log" file for the line "Wedge detected."  If you see it, please upload the log file.
Cc: jansson@chromium.org
See https://code.google.com/p/chromium/issues/detail?id=168987
People are entering comments there about the same issue even though it's been marked as will not fix.

Comment 52 by gam...@gmail.com, Oct 28 2013

dalecurtis: I have been testing your build for 2 days straight and the problem didn't appear. It did appear nonetheless in my "normal" chrome which I had running in parallel.

Might it be caused by some extension or maybe the number of tabs is a factor?
I had this happen on a MacBookPro10,1 with 10.9 this weekend.

Comment 54 by srulix@google.com, Oct 28 2013

I can confirm this happens Macbook Air... Version 30.0.1599.69...
Issue 168987 has been merged into this issue.
gamell: Did you see any "Wedge detected." lines in the "/tmp/.data/chrome_debug.log" file?  My new build will self-correct if it detects a problem.  You can check this by running:

grep "Wedge detected" /tmp/.data/chrome_debug.log

I think it is related to the number of tabs and streams you have open.  Most users who reproduce the issue report having lots of tabs open.

Comment 57 by gam...@gmail.com, Oct 31 2013

dalecurtis: no sign of "wedge detected" in the log. I will open more tabs and keep testing. Thanks!
Seeing this issue as well.

Chrome 31.0.1650.39 beta, OS X 10.9 (13A603), MacBook Air 13-inch, Mid 2011

I am going to download the instrumented build...

 Issue 314363  has been merged into this issue.
Next time anyone hits this can you lookup the browser process id from "Tools -> Task Manager" and then run "lsof -p <process id> in the command line?  You should get something like:

...
chrome  25521 dalecurtis  236u   REG               8,16      3072  4342735 /d/.config/google-chrome-beta/Default/Local Storage/https_chrome.google.com_0.localstorage
chrome  25521 dalecurtis  237u   REG               8,16      3072  4342306 /d/.config/google-chrome-beta/Default/Local Storage/https_sites.google.com_0.localstorage
chrome  25521 dalecurtis  240u   REG               8,16      3072  4342254 /d/.config/google-chrome-beta/Default/Local Storage/https_groups.google.com_0.localstorage
chrome  25521 dalecurtis  242u  unix 0x0000000000000000       0t0   814304 socket
chrome  25521 dalecurtis  243u   REG               8,16      7168  4342255 /d/.config/google-chrome-beta/Default/Local Storage/https_www.youtube.com_0.localstorage
chrome  25521 dalecurtis  252u  IPv6             808693       0t0      TCP [2620:0:1009:2:6e3b:e5ff:fe0b:705b]:53229->sea09s17-in-x03.1e100.net:https (ESTABLISHED)
chrome  25521 dalecurtis  260r  sock                0,7       0t0   797257 can't identify protocol

Please report the last number you see in the 4th column (e.g., "260" in this example).
Project Member

Comment 61 by bugdroid1@chromium.org, Nov 5 2013

------------------------------------------------------------------------
r232796 | dalecurtis@google.com | 2013-11-04T21:12:02.229235Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac.cc?r1=232796&r2=232795&pathrev=232796
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_manager_mac.h?r1=232796&r2=232795&pathrev=232796

Improve error handling and revert old debugging code.

This pulls out some of the extra debugging code I've added for the
debug builds I've been handing out.  Specifically:
- Checks error status on Start() and Stop().
- Ensures preconfigured AudioBus channel count matches
buffer list count.
- Removes old debugging code that is never triggered.

BUG=160920
TEST=none
R=scherkus@chromium.org

Review URL: https://codereview.chromium.org/56053003
------------------------------------------------------------------------
Project Member

Comment 62 by bugdroid1@chromium.org, Nov 5 2013

------------------------------------------------------------------------
r233034 | dalecurtis@chromium.org | 2013-11-05T18:32:57.240173Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/metrics/histograms/histograms.xml?r1=233034&r2=233033&pathrev=233034
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.cc?r1=233034&r2=233033&pathrev=233034
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.h?r1=233034&r2=233033&pathrev=233034

Add AudioOutputController trace events and UMA backed wedge detection.

More extraction of debug code from my local test build.  This adds:
- Trace events for easy logging of AudioOutputController actions.
- A wedge detection UMA statistic for field monitoring.

BUG=160920
TEST=UMA stat is reported correctly when wedged and not.

Review URL: https://codereview.chromium.org/51003005
------------------------------------------------------------------------
@Dale #60: I wasn't sure whether you mean folks using your special build or any build.  

I'm on the Chrome Stable channel (on Mac OS 10.8.5) and I see "884u" in the fourth column after following your instructions.
Thanks Paul.  I meant for anyone.  Are you still seeing the issue on 10.8.5?  There's a suspicious looking fix from Apple in the changelogs: 

"Addresses an issue that may prevent HDMI audio from working after waking from sleep"
http://support.apple.com/kb/DL1686

We've also had some reports that users are seeing this issue fixed in M32.  Can some of you try Chrome Canary or the M32 Dev Channel and see if the issue is resolved for you?

https://www.google.com/intl/en/chrome/browser/canary.html


I saw that change log and wondered the same thing, but I am definitely still seeing the issue.  As for being fixed in Dev, are those two new patches already in the the Dev build?  

Maintaining my (rather large) list of tabs is important to my workflow, so unless there's a way to have Chrome Canary recreate all of my currently open tabs, I'll probably let others do the testing with Dev and / or wait for the Dev build to trickle down to Stable.
Still seeing in 10.9 on 32.0.1700.6 dev

Experience is: play a YouTube or Vimeo video, it has no audio and video stalls as well. Run 'sudo killall coreaudiod' and all of a sudden the audio comes back, video restarts, and a bunch of Chrome-generated audio - pings from Hangouts, etc, all play instantly.
The latest two patches are just monitoring improvements, they shouldn't actually fix anything.

Canary can be installed side by side with your current installation, so you can try it out without disrupting your existing tabs.  If you're using Chrome Sync I think you can replicate the tabs into Canary as well.
Thanks for the unfortunate data point pawliger@.

To all: If you're feeling adventurous, the next time this happens can you please try the following:

WARNING: Another user reported this hard locked their system, so make sure anything important is saved before continuing.

1. Open a tab with chrome://media-internals
2. Close all other tabs one by one (streams should slowly disappear from media-internals).
3. Verify nothing is listed in chrome://media-internals.
4. Try to play http://commondatastorage.googleapis.com/dalecurtis-shared/buck2.webm

Does the video play or continue to hang?  What's in chrome://media-internals?  Additionally, if you have "sample" installed, please look up the Chrome Browser process id from Chrome's Task Manager and run:

sample <process id> -file chrome-sample.txt

It should create a report after some time.  Please upload chrome-sample.txt.  If you're running canary, please also report the contents of: chrome://histograms/Media.AudioOutputControllerPlaybackStartupSuccess

Thanks in advance!
Project Member

Comment 69 by bugdroid1@chromium.org, Nov 8 2013

------------------------------------------------------------------------
r233843 | dalecurtis@chromium.org | 2013-11-08T09:28:51.683681Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.cc?r1=233843&r2=233842&pathrev=233843

Ensure the wedge timer isn't started until after StartStream().

Otherwise, in rare conditions, a very long StartStream() may
incorrectly cause a wedge to be flagged.

If StartStream() hangs the message loop is blocked and the timer
will never run anyways.

Also, increase wedge timer to 5 seconds.

BUG=160920
TEST=none

Review URL: https://codereview.chromium.org/64493003
------------------------------------------------------------------------
Cc: sarahmorales@chromium.org
#66 - We're seeing users on the forum report the same issue you describe (no audio, video stalls), but the users who have tried Canary indicates that audio/video is fine. (https://productforums.google.com/forum/#!msg/chrome/jTu_YI1NgdE/5uQpNjMc1wEJ) Is this the right bug to follow or is there another bug that tracks the issue?
melody: Yes, it sounds like the same issue.  I'm glad to hear M32 is helping out some users; others are still reporting issues on M32 though.

Comment 72 by gam...@gmail.com, Nov 12 2013

#68, dalecurtis

It just happened to me again, I followed your steps and the issue was solved. This is how media internals looked when the issue happened, after closing all tabs but this one (and media internals) and after playing the video you linked (which played fine):

1- initially
===========

Active media players:
Active audio streams:
Audio stream 0x6e2525d0:47 is paused
Audio stream 0x76314dc0:14 is playing
Audio stream 0x7696e470:4 is paused
Audio stream 0x772b93c0:1 is paused
Audio stream 0x81e68aa0:13 is playing
Audio stream 0x8218d700:6 is playing
Audio stream 0x82244c10:2 is paused
Audio stream 0x82841eb0:1 is paused
Audio stream 0x8694d040:7 is paused
Cached resources:

2- after closing all tabs but one
================================

Active media players:
URL Unknown
https://ssl.gstatic.com/chat/sounds/incoming_video_short_5abdd7c1c7fa8bbd5d6b4733de315c59.mp3
Buffered	
Active audio streams:
Audio stream 0x82841eb0:1 is paused
Cached resources:

3- Playing the video:
====================

Active media players:
URL Unknown
https://ssl.gstatic.com/chat/sounds/incoming_video_short_5abdd7c1c7fa8bbd5d6b4733de315c59.mp3
Buffered	
http://commondatastorage.googleapis.com/dalecurtis-shared/buck2.webm
Buffered	
Cache Reads	
Cache Writes	
Active audio streams:
Audio stream 0x774e21e0:1 is playing
Audio stream 0x82841eb0:1 is paused
Cached resources:

Thanks gamell. That's interesting, it looks like you were able to keep a stream alive and still have sound come back correctly.  I.e., you didn't need to close all audio tabs to get audio back.  Which makes me think there's a specific tab causing problems.

Thanks for your help!

Next time you encounter this can you open the test video (buck2) in one tab and then start closing tabs one-by-one like last time.  However, as each tab is closed, please refresh (F5, Ctrl-R, etc) the tab with the test video.  Please let me know which tab closure (if any) causes the test video to start playback again.

Update: At this point we're pretty sure it's an OS level issue.  I've created a minimized test case, https://codereview.chromium.org/63823006/ , which we'll send to Apple and see what they say. If they confirm that it's an OS issue I've prepared a workaround that we can deploy until a fix is available: https://codereview.chromium.org/61203008/
Just a comment, not sure how much value it would add.  
I don't know what's changed, however I don't seem to be suffering from this issue anymore (within 1-2 weeks)  The only thing I think I have done is:

a) Relaunched Chrome
b) Rebooted my Mac to install software

As simple as it might sound, has anyone else with this issue actually rebooted their Mac recently and still suffers the issue?
Filed as rdar://15485249 ( http://openradar.appspot.com/radar?id=5218579611910144 )
Just to update, issue has come back for me.  Followed instructions by Dale about, last value is 391u.  Full output attached.

In addition I tried the audio stream test above.   Initially I had 3 audio streams:
audio_streams.0x7edeb040:1
audio_streams.0x7fb84e70:1
audio_streams.0x81645a10:2

However when closing tabs, these stayed in the media-internals tab. 
I then tried to play the Buck video which added an additional stream:
audio_streams.0x80bc6840:1
though there was no sound and the video didn't actually play (might have been a buffering issue)
output.rtf
65.7 KB Download
greg.hesp: Thanks for your continued debugging help.

At this point we're pretty sure there's an OS level issue and have filed a bug with Apple. Hopefully we'll have a workaround or update from Apple soon.
Project Member

Comment 79 by bugdroid1@chromium.org, Nov 21 2013

------------------------------------------------------------------------
r236378 | dalecurtis@chromium.org | 2013-11-21T02:37:56.424125Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac.cc?r1=236378&r2=236377&pathrev=236378
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac.h?r1=236378&r2=236377&pathrev=236378

Dynamically FIFO when OSX requests unexpected frame counts.

Previously we would just return silence in this case.  However we
did not invoke the AudioSourceCallback which would leave clients
hanging.

Traces don't seem to indicate this is the cause of OSX audio
dropouts (the "AUHALStream::Render" traces are not even present
when the bug occurs).  However I'd like to remove all instances
where we're returning silence w/o triggering an error.

This change fixes an additional issue where we weren't calculating
the latency correctly.  Chrome expects the AudioBuffersState to be
calculated for all channels, while CoreAudio expects mBytesPerFrame
to be sizeof(Float32) for planar data.

BUG=160920
TEST=force buffer size increase/decrease, check playback is okay.

Review URL: https://codereview.chromium.org/70903002
------------------------------------------------------------------------
Cc: priyanks@chromium.org
 Issue 324113  has been merged into this issue.
Project Member

Comment 82 by bugdroid1@chromium.org, Dec 3 2013

------------------------------------------------------------------------
r238325 | dalecurtis@google.com | 2013-12-03T08:09:24.162874Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.cc?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.h?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.h?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.cc?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher.h?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.h?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.cc?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager.h?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.h?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_proxy_unittest.cc?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.cc?r1=238325&r2=238324&pathrev=238325
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.cc?r1=238325&r2=238324&pathrev=238325

Attempt to fix audio wedges by restarting all streams on OSX.

Introduces two new methods to AudioOutputDispatcher:
CloseStreamsForWedgeFix() and RestartStreamsForWedgeFix().

Respectively, each method closes or restarts all active
streams owned by a given dispatcher.  The process is
completely transparent to upstream clients.

A new method on AudioManager, FixWedgedAudio() calls
CloseStreamsForWedgeFix() for all dispatchers and then
calls RestartStreamsForWedgeFix() afterward.

FixWedgedAudio() is called by each AudioOutputController
when a wedge is detected.  Multiple in flight wedge checks
are serialized by the audio thread.  The hope is that wedges
will be fixed before the next WedgeCheck() fires.

While the methods are available on all platforms, FixWedgedAudio()
is only wired up on OSX.

BUG=160920
TEST=unittest. fake wedge and observe stream recreation.
R=scherkus@chromium.org

Review URL: https://codereview.chromium.org/61203008
------------------------------------------------------------------------
Project Member

Comment 83 by bugdroid1@chromium.org, Dec 3 2013

------------------------------------------------------------------------
r238327 | dubroy@chromium.org | 2013-12-03T09:33:05.812434Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager.h?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.h?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_proxy_unittest.cc?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.cc?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.cc?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.cc?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.h?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.h?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.cc?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher.h?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.h?r1=238327&r2=238326&pathrev=238327
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.cc?r1=238327&r2=238326&pathrev=238327

Revert 238325 "Attempt to fix audio wedges by restarting all str..."

> Attempt to fix audio wedges by restarting all streams on OSX.
> 
> Introduces two new methods to AudioOutputDispatcher:
> CloseStreamsForWedgeFix() and RestartStreamsForWedgeFix().
> 
> Respectively, each method closes or restarts all active
> streams owned by a given dispatcher.  The process is
> completely transparent to upstream clients.
> 
> A new method on AudioManager, FixWedgedAudio() calls
> CloseStreamsForWedgeFix() for all dispatchers and then
> calls RestartStreamsForWedgeFix() afterward.
> 
> FixWedgedAudio() is called by each AudioOutputController
> when a wedge is detected.  Multiple in flight wedge checks
> are serialized by the audio thread.  The hope is that wedges
> will be fixed before the next WedgeCheck() fires.
> 
> While the methods are available on all platforms, FixWedgedAudio()
> is only wired up on OSX.
> 
> BUG=160920
> TEST=unittest. fake wedge and observe stream recreation.
> R=scherkus@chromium.org
> 
> Review URL: https://codereview.chromium.org/61203008

TBR=dalecurtis@google.com

Review URL: https://codereview.chromium.org/101473002
------------------------------------------------------------------------
Project Member

Comment 85 by bugdroid1@chromium.org, Dec 4 2013

------------------------------------------------------------------------
r238501 | dalecurtis@google.com | 2013-12-04T00:45:47.194489Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.h?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.h?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.cc?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher.h?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.h?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.cc?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager.h?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.h?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_proxy_unittest.cc?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.cc?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.cc?r1=238501&r2=238500&pathrev=238501
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.cc?r1=238501&r2=238500&pathrev=238501

Attempt to fix audio wedges by restarting all streams on OSX.

Introduces two new methods to AudioOutputDispatcher:
CloseStreamsForWedgeFix() and RestartStreamsForWedgeFix().

Respectively, each method closes or restarts all active
streams owned by a given dispatcher.  The process is
completely transparent to upstream clients.

A new method on AudioManager, FixWedgedAudio() calls
CloseStreamsForWedgeFix() for all dispatchers and then
calls RestartStreamsForWedgeFix() afterward.

FixWedgedAudio() is called by each AudioOutputController
when a wedge is detected.  Multiple in flight wedge checks
are serialized by the audio thread.  The hope is that wedges
will be fixed before the next WedgeCheck() fires.

While the methods are available on all platforms, FixWedgedAudio()
is only wired up on OSX.

BUG=160920
TEST=unittest. fake wedge and observe stream recreation.
R=scherkus@chromium.org

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

Review URL: https://codereview.chromium.org/61203008
------------------------------------------------------------------------
Relanded after fixing SoundsManager here: https://codereview.chromium.org/102693003/
A workaround has landed in today's canary. Please check it out and update if you still experience the issue or other weirdness.

The way the workaround works is by detecting when audio has wedged and then closing and reopening all streams. The wedge detection is on a 5 second timer, which is hopefully transparent to the user since the issue appears immediately after resume in response to automated playbacks. The timer window doesn't leave a lot of time for user interaction, just enough that we shouldn't be triggering false positives.

With that in mind, please especially report anything weird you see or hear around the 5 second mark after resume. The most likely complaint is that all automated playbacks will spill audio out at once. 
I have the same problem. Put Macbook Pro 10.8.x to sleep and when it wakes the audio on chrome does not work. Force quit chrome and reopen and viola it works again. Tad bit annoying - wish it was fixed.
 Issue 326673  has been merged into this issue.
Cc: tkonch...@chromium.org
 Issue 317349  has been merged into this issue.

Comment 91 by kareng@google.com, Dec 12 2013

Labels: Merge-Approved M-32
Project Member

Comment 92 by bugdroid1@chromium.org, Dec 12 2013

Labels: -Merge-Approved merge-merged-1700
------------------------------------------------------------------------
r240453 | dalecurtis@google.com | 2013-12-12T22:46:23.982179Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_dispatcher.h?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_dispatcher_impl.h?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_resampler.cc?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_manager.h?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_resampler.h?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_proxy_unittest.cc?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_controller.cc?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/mock_audio_manager.cc?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_manager_base.cc?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/mock_audio_manager.h?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_manager_base.h?r1=240453&r2=240452&pathrev=240453
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_dispatcher_impl.cc?r1=240453&r2=240452&pathrev=240453

Merge 238501 "Attempt to fix audio wedges by restarting all stre..."

> Attempt to fix audio wedges by restarting all streams on OSX.
> 
> Introduces two new methods to AudioOutputDispatcher:
> CloseStreamsForWedgeFix() and RestartStreamsForWedgeFix().
> 
> Respectively, each method closes or restarts all active
> streams owned by a given dispatcher.  The process is
> completely transparent to upstream clients.
> 
> A new method on AudioManager, FixWedgedAudio() calls
> CloseStreamsForWedgeFix() for all dispatchers and then
> calls RestartStreamsForWedgeFix() afterward.
> 
> FixWedgedAudio() is called by each AudioOutputController
> when a wedge is detected.  Multiple in flight wedge checks
> are serialized by the audio thread.  The hope is that wedges
> will be fixed before the next WedgeCheck() fires.
> 
> While the methods are available on all platforms, FixWedgedAudio()
> is only wired up on OSX.
> 
> BUG=160920
> TEST=unittest. fake wedge and observe stream recreation.
> R=scherkus@chromium.org
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=238325
> 
> Review URL: https://codereview.chromium.org/61203008

TBR=dalecurtis@google.com

Review URL: https://codereview.chromium.org/99173007
------------------------------------------------------------------------
Project Member

Comment 93 by bugdroid1@chromium.org, Dec 13 2013

------------------------------------------------------------------------
r240691 | dalecurtis@google.com | 2013-12-13T17:48:29.756872Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_controller.cc?r1=240691&r2=240690&pathrev=240691

Merge 233843 "Ensure the wedge timer isn't started until after S..."

> Ensure the wedge timer isn't started until after StartStream().
> 
> Otherwise, in rare conditions, a very long StartStream() may
> incorrectly cause a wedge to be flagged.
> 
> If StartStream() hangs the message loop is blocked and the timer
> will never run anyways.
> 
> Also, increase wedge timer to 5 seconds.
> 
> BUG=160920
> TEST=none
> 
> Review URL: https://codereview.chromium.org/64493003

TBR=dalecurtis@chromium.org

Review URL: https://codereview.chromium.org/108113004
------------------------------------------------------------------------
Project Member

Comment 94 by bugdroid1@chromium.org, Dec 13 2013

------------------------------------------------------------------------
r240690 | dalecurtis@google.com | 2013-12-13T17:47:42.517062Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_controller.cc?r1=240690&r2=240689&pathrev=240690
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/media/audio/audio_output_controller.h?r1=240690&r2=240689&pathrev=240690
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/tools/metrics/histograms/histograms.xml?r1=240690&r2=240689&pathrev=240690

Merge 233034 "Add AudioOutputController trace events and UMA bac..."

> Add AudioOutputController trace events and UMA backed wedge detection.
> 
> More extraction of debug code from my local test build.  This adds:
> - Trace events for easy logging of AudioOutputController actions.
> - A wedge detection UMA statistic for field monitoring.
> 
> BUG=160920
> TEST=UMA stat is reported correctly when wedged and not.
> 
> Review URL: https://codereview.chromium.org/51003005

TBR=dalecurtis@chromium.org

Review URL: https://codereview.chromium.org/112413005
------------------------------------------------------------------------
I have this issue as well on latest chrome build (stable) on maverick.  This has been happening for several months, pretty much every time my notebook sleeps.
Looks like plugging and then unplugging headphones seems to "fix" the audio/video not working.
 Issue 330877  has been merged into this issue.

Comment 98 by dmbw...@gmail.com, Jan 3 2014

Disabled one flash plug in .. now it is working ???  Hope it continues..
much aloha...

I'll keep using Chrome......mahalo


don
I was able to reproduce with Chrome 31.0.1650.63 and Mac OS X 10.9.1. I only have one copy of Flash under chrome://plugins:

Version: 11.9.900.170
Shockwave Flash 11.9 r900
 Issue 333987  has been merged into this issue.
 Issue 333987  has been merged into this issue.

Comment 102 by sata...@gmail.com, Jan 16 2014

Problem appears to have gotten worse in 32.0.1700.77 (Official Build 244503) ?

Comment 103 by dmbw...@gmail.com, Jan 16 2014

Not seeing improvements, disabled all plugins not familiar with. Worked for awhile.  Going to use firefox until someone solves this issue.
@satadru, dmbwest: To confirm we're talking about the same issue, after resume you're still losing audio sometimes?  Or all the time?  Does audio work at all in Chrome for you?

Comment 105 by sata...@gmail.com, Jan 16 2014

@dalecurtis Audio was working last night, and not earlier today.  In between the laptop was put to sleep.

Last night I updated to 32.x

At wakeup I have a script I run that does a "sudo killall coreaudiod" - since that seemed to fix things over the last several months.

I'm also running a build of 10.9.2, which probably complicates things.
@satadru: Can you try switching to a canary build for a little while?

https://www.google.com/intl/en/chrome/browser/canary.html

Then if you hit this issue again, let me know what chrome://media-internals says.

I'll explore an alternate workaround for this issue too.  Locally, for me, the current workaround works, but it could certainly have adverse effects or fail to work in some cases.

Comment 107 by Deleted ...@, Jan 20 2014

I have just started receiving this issue a few days ago. Flash videos work fine but audio cuts out. The only way to restore audio is to refresh the page or restart the browser. 
ARamsey833: What version of Chrome are you seeing this issue on?
Project Member

Comment 109 by bugdroid1@chromium.org, Jan 25 2014

------------------------------------------------------------------------
r247026 | dalecurtis@chromium.org | 2014-01-25T00:11:19.236820Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac_unittest.cc?r1=247026&r2=247025&pathrev=247026
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac.cc?r1=247026&r2=247025&pathrev=247026
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_manager_mac.cc?r1=247026&r2=247025&pathrev=247026
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac.h?r1=247026&r2=247025&pathrev=247026
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_manager_mac.h?r1=247026&r2=247025&pathrev=247026

Defer OSX output stream Start() around system supend and resume.

Uses base::PowerMonitor to watch for suspend and resume events and
disables stream creation during suspend and for a second after a
resume is detected.

Since Start() is asynchronous anyways, this is pretty self contained
change.  If Stop() occurs before the deferred Start(), the pending
task is simply canceled.

This method has the advantage of preemptively preventing stream hangs
instead of trying to correct them after the fact.  It's also far less
invasive than the "restart all streams" workaround.  A risk is that
the post-resume delay is not long enough.

BUG=160920
TEST=repeated start/stop no longer fails.
NOTRY=true

Review URL: https://codereview.chromium.org/135853022
------------------------------------------------------------------------
Still a little early to tell, but on dev channel the UMA stat which tracks instances of this failure (AudioOutputControllerPlaybackStartupSuccess) went from 0.65% of playbacks to 0.26% of playbacks - so it appears to be working better than the previous workaround.

The next step will be to revert the original workaround and see if the metric remains low.
I have no audio on any site I try. Does not matter if it is a video or a game played on line Version 33.0.1750.146 m is the version I am using.  I even had my tech support for my computer check it out.  No luck.

I'm removing the original hacky workaround for this issue(*) in favor a more elegant approach based on deferring stream creation during suspend and resume. This should appear in tomorrow's canary. Testing shows this approach should be more effective, but I'll be closely watching the statistics to ensure the original issue does not reappear. If anyone sees any issues on M36 in the coming days / weeks, please let me know immediately.

[1]: https://codereview.chromium.org/190553004/
Project Member

Comment 114 by bugdroid1@chromium.org, Apr 10 2014

------------------------------------------------------------------
r263076 | dalecurtis@chromium.org | 2014-04-10T21:01:09.150178Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_proxy_unittest.cc?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_controller.cc?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.cc?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.cc?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mock_audio_manager.h?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager_base.h?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.cc?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher.h?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_dispatcher_impl.h?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.cc?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_manager.h?r1=263076&r2=263075&pathrev=263076
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_output_resampler.h?r1=263076&r2=263075&pathrev=263076

Revert "Attempt to fix audio wedges by restarting all streams on OSX."

This reverts commit http://crrev.com/238501 in favor  a simpler approach
which delays stream creation around suspend and resume events:
http://crrev.com/247026

Care must be taken to monitor the UMA stat for increases after this lands.
I'll also communicate with the YT team on the bug/ to ensure they provide
some assistance in testing.

BUG=160920
TEST=No stream hangs.

Review URL: https://codereview.chromium.org/190553004
-----------------------------------------------------------------
Measure with similar sample populations on M33 and M34, the new fix appears to have reduced our failure rate from 0.54% to 0.30% on OSX. \o/

Hopefully that record remains the same once the hacky workaround is removed.  We're also looking at deferring input streams on OSX too:

https://codereview.chromium.org/233823003/
Project Member

Comment 116 by bugdroid1@chromium.org, Apr 16 2014

------------------------------------------------------------------
r264073 | dalecurtis@chromium.org | 2014-04-16T02:35:58.285053Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_auhal_mac.cc?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_manager_mac.cc?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_manager_mac.h?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_input_unittest.cc?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_low_latency_input_mac_unittest.cc?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.cc?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_low_latency_input_mac.cc?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.h?r1=264073&r2=264072&pathrev=264073
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_low_latency_input_mac.h?r1=264073&r2=264072&pathrev=264073

Defer input stream start around suspend and resume.

As with output streams on OSX, we should defer input stream starts
around suspend and resume.

UMA statistic rates for M33 -> M34 show us going from 0.54% to 0.30%
failures! Lets see if we can go even further.

BUG=160920, 361999 
TEST=none

Review URL: https://codereview.chromium.org/233823003
-----------------------------------------------------------------
Apple just pinged me to say they believe the root cause rdar://15485249 ( http://openradar.appspot.com/radar?id=5218579611910144 ) is fixed in OSX Yosemite.

I'll try to get a Yosemite setup and see if the issue is resolved. That said I think we may want to keep deferall around suspend/resume anyways as a preventative measure.
I've verified this is resolved on Yosemite.
Project Member

Comment 120 by bugdroid1@chromium.org, Jul 16 2015

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

commit 50a8c9d4ccf77929d4a4e79b61318a3b46147137
Author: dalecurtis <dalecurtis@chromium.org>
Date: Thu Jul 16 02:09:14 2015

Increase OSX post-resume delay for new audio streams.

Still seem to be occasional reports of this happening, so increase
the post-resume delay to two seconds.

The UMA stat for OSX is still much higher than other platforms,
0.5% for OSX, but 0.01% for Windows.  I'll monitor the UMA values
to see if those values go down after landing this.

BUG=160920
TEST=none

Review URL: https://codereview.chromium.org/1230023009

Cr-Commit-Position: refs/heads/master@{#338970}

[modify] http://crrev.com/50a8c9d4ccf77929d4a4e79b61318a3b46147137/media/audio/mac/audio_manager_mac.h

Issue 622405 has been merged into this issue.
Status: ExternalDependency (was: Fixed)
Looks like this is happening again, we have a bug outstanding with apple b/29521950
Cc: henrika@chromium.org
Apple has requested a sysdiagnose capture. If anyone hits this, please follow the instructions here and upload the report to this bug.

sysdiagnose Instructions:
https://developer.apple.com/services-account/download?path=/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf
Cc: smus@chromium.org
Blocking: 669773
Issue 672756 has been merged into this issue.
Project Member

Comment 128 by bugdroid1@chromium.org, May 4 2017

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

commit 810fd109a32f93c82837265bc196d932ad5690af
Author: ossu <ossu@chromium.org>
Date: Thu May 04 08:59:56 2017

Have AUAudioInputStream::Stop() also cancel any deferred start.

BUG=160920
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

Review-Url: https://codereview.chromium.org/2860653003
Cr-Commit-Position: refs/heads/master@{#469296}

[modify] https://crrev.com/810fd109a32f93c82837265bc196d932ad5690af/media/audio/mac/audio_low_latency_input_mac.cc

Labels: -Merge-Merged-1700 -GlutenFree -M-32
Label cleanup...

Comment 130 Deleted

Cc: ossu@chromium.org
Cc: solenberg@chromium.org
Owner: ossu@chromium.org
Handing over to ossu@ since he's the one working on this now.
Cc: spqc...@chromium.org kkaluri@chromium.org
 Issue 670235  has been merged into this issue.
Cc: -ashej...@chromium.org
In the WebRTC Update 2017 talk recorded at the Kranky Geek 2017 event held at Google last friday, Justin Uberti (Engineering lead for WebRTC in Chrome) mentioned this issue and talks a lot about the fix that'll be shipped in Chrome 63:
https://youtu.be/PEXnbTyygi4?t=10m33s

There's more talk about solving audio issues at minute 15
https://youtu.be/PEXnbTyygi4?t=15m36s

Comment 137 by ossu@chromium.org, Nov 14 2017

Blockedon: 772884 772410

Comment 138 by ossu@webrtc.org, Nov 14 2017

Blocking: webrtc:4799

Comment 139 by ossu@chromium.org, Nov 14 2017

Summarizing the progress of this bug:

I've found a couple of seemingly errant behaviors in CoreAudio that together cause this to problem to happen.  Issue webrtc:4799  indicates this problem happens during system suspend and wakeup. This is also where the errant behavior was identified. The findings have been thoroughly detailed and reported as a bug to Apple.

For the time being, I've put together a workaround (see: chromium:772410), which works only on macOS 10.10 and later. The workaround is in Chrome M63 and has also been merged to M62, see: chromium:772884. It is being rolled out in a controlled fashion over the coming days and weeks.

As indicated by the video in comment #136, the stats we have indicate that this workaround has a significant effect on this source of errors.

Thanks you for the work done on this issue and the heads up.

What versions of Chrome 62 will we the fix be merged in? I'm running 62.0.3202.89 (I can not access chromium: 772884).

Comment 141 by ossu@chromium.org, Nov 14 2017

I believe it should be in 62.0.3202.94. The fix itself is rolled out as an experiment, so it won't reach the whole population immediately, even after they get on that version. I'll post an update once we've narrowed down the time frame a bit.
The WebRTC Update 2017 talk mentions that this bug has already been fixed and will land in Chrome 63 in December, yet this bug report has been updated only to show that it is blocked. Can someone who know more details please clarify for us? We have quite a few MacOS customers encountering this problem right now.

Comment 143 by ossu@chromium.org, Nov 15 2017

The root cause of this bug is outside of Chrome and, as such, this bug is set as ExternalDependency. We're still tracking the bug in Apple's bugtracker. I expect we'll update this bug once we have more news on that.

As for the workaround ( bug 772410 ), I've now marked that one as fixed. It will land in Chrome 63 in December and we're working on pushing it out to users of M62 as well.

I hope this clears up any confusion.

Comment 144 by ossu@chromium.org, Nov 24 2017

The fix has now been enabled for the whole population on all channels of M62 and M63. For individual users, this will only apply once Chrome is (re-)started.

Comment 145 by ossu@chromium.org, Dec 22 2017

Issue 769349 has been merged into this issue.
Cc: chcunningham@chromium.org mlamouri@chromium.org olka@chromium.org dalecur...@chromium.org wolenetz@chromium.org guidou@chromium.org
 Issue 791728  has been merged into this issue.
Cc: ranjitkan@chromium.org w...@chromium.org tommi@chromium.org kbr@chromium.org wdzierza...@opera.com maxmorin@chromium.org tvsriram@chromium.org hongchan@chromium.org
 Issue 549021  has been merged into this issue.
Showing comments 48 - 147 of 147 Older

Sign in to add a comment