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

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Closed: Dec 21
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocked on: View detail
issue chromium:160920
issue chromium:672469

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment
User on OS X does not have microphone input signal even when system shows input audio
Reported by, Jun 26 2015 Back to list
No clear steps to reproduce. 

Discuss Webrtc thread here:

What steps will reproduce the problem?
1. Use a webrtc application like Hangouts successfully with microphone input
2. Stop using the application
3. At some future point, use the same application

What is the expected result?
User has microphone input

What do you see instead?
No microphone input signal. OS shows microphone input signal but no audio comes through microphone. 

What version of the product are you using? On what operating system?
Chrome: 43.0.2357.130 OS X 10.10.3 (14D136)

Please provide any additional information below.

Happens to our application ( and in a couple of instances we've had users try Hangouts and see the same behavior. Makes me think it's Chrome related. 

I realize this is a vague bug. Next time I see a live case of it on a computer we can access, I can get more stats or try the page 

Two notes:

1) This anecdotally happens more after a Mac that was using Chrome goes to sleep and then is resumed.

2) Restarting Chrome (the entire application) fixes the problem. 
Project Member Comment 2 by, Jun 29 2015
I just did a Chrome update on OSX moment ago and apprtc demo still works well after it.
Apprtc demo also can be started normally after I close/open MBP lid while using chrome. 

We'll keep an eye on it during our testing. 
Project Member Comment 3 by, Jul 14 2015
The problem with issues like this is that most likely logs containing information AFTER the issue is present does not reveal to much. Ideally we want logs when it breaks but can be really hard to achieve especially when we do not have a narrow test case.

To give us some more info, please join a hangout call and when the issues is present, hang up and then browse to chrome://webrtc-logs and attach the latest log here.

We have received reports of this issue happening with our application (Blue Jeans) as well. When it happens, no signal is received from the microphone for all Chrome WebRTC applications (e.g. AppRTC,, and Hangouts). Meanwhile, the microphone still works for other native applications and the audio level meter in the system settings reacts to input sounds. The only workaround we have is to quit and restart Chrome.

The next time this happens, we can gather any information required. Please let us know what steps we should take. chrome://webrtc-logs seems to always show 0 logs.
Project Member Comment 5 by, Jul 24 2015
1ee@, thanks for help!
Having no much idea yet, I wonder if Mic fails with Chrome Stable, will it work with Canary on the same machine, or will it work with native WebRTC if you ever build one? If yes, then we can try to collect the logs. The best case is we can get log from voe_cmd_test of native webrtc. Otherwise maybe always open Chrome with logging enabled as
 --enable-logging --v=4 --vmodule=*/webrtc/*=4,*media/audio/*=3,*/libjingle/*=2

Let's see if we can get anything valuable from it.
Is there any other way we can gather information or logs from Chrome after this issue is hit? We have had numerous confirmed instances of this issue, but it is very difficult to reproduce on-demand. Consistently launching Chrome with the command-line flags is difficult for many folks, the log file grows very quickly in size, and there are concerns about logging of private information.
Going into the system preferences and manually moving a slider on the right input source fixes it, too. I know that's just as un-usable as launching Chrome with a flag, but at least you don't have to close the browser.
Project Member Comment 8 by, Aug 25 2015
Re#7: that means either an application or a user has muted the microphone, the AGC (auto gain control) cannot recover from that state as it only adjusts the volume, it does not change the muted state (by design). 

To clarify moving the slider all the way to the left, i.e. 0 results in mute, Chrome then adjusts the volume to 33% when getUserMedia is called, however it's still left in the muted state, the slider will indicate 33% volume but there is no mute indicator. 

You can however see it in the midi setup:
Project Member Comment 9 by, Sep 29 2015
Labels: Area-GetUserMedia-Mic
Any updates as to whether the fix mentioned in #7 works for other folks seeing this bug? Trying to determine if this is an AGC issue or a capture issue.
I think we're mixing up issues here with #7. The original issue as described by the reporter and corroborated by user reports on our (Blue Jeans) side is that the OS System Preferences sound panel input level animates correctly given voice activity, and other desktop applications successfully get the microphone signal, but Chrome web applications cannot get the microphone signal.
Project Member Comment 11 by, Oct 1 2015
Re #4 chrome://webrtc-logs are only populated from hangout calls.
Re #10 Yes that seems to be the case.

Also I just want to clarify, are you still seeing this issue in later versions than M43 of chrome?

tommi@, henrika@ what information can we ask the user to collect in order for us to debug this further? 

FTR I've tried to repro this on demand but have not been successful, however I've also seen the issue a couple of times (cannot remember on which version though) but unfortunately did not have this bug in mind so I just restarted chrome to be able to join a meeting or whatever it was.

Project Member Comment 12 by, Oct 1 2015
Project Member Comment 13 by, Oct 1 2015
Re #11, adding the output from chrome://media-internals (under the audio tab) can be useful. There is currently no logging available for all clients from the lowest media level but it might be possible to add. Adding henrikg@ who might be able to do work in this area.
Re #11, yes, this was most recently reported yesterday on version 45.0.2454.93. Besides the microphone signal not being received, even audio output was not heard in Chrome (WebRTC apps and YouTube). Meanwhile other desktop apps like Spotify worked fine. The OS System Preferences sound panel input level animated correctly. Unfortunately debug logging had not previously been enabled on Chrome.
Project Member Comment 15 by, Oct 2 2015
To get some logging information: if you get this when using Hangouts, please close the call with the hang up button in the UI, then go to chrome://webrtc-logs and find the call recently made and provide the report ID.
Re #15, I've tried numerous times to gather logs (when there are no symptoms) by joining Hangouts from Chrome, hanging up, and checking chrome://webrtc-logs, but I never see any logs there. Will logs only be generated if Chrome detects a Hangouts problem?
Project Member Comment 17 by, Nov 3 2015
Hangouts should always generate a log, but you would need to opt in to do this. However, I have done so on a non-corp account and yet no logs are shown in the list. I'll check with the Hangouts team what the log generation story is.
Project Member Comment 18 by, Nov 3 2015
Project Member Comment 19 by, Nov 3 2015
We have new stats in Canary for Mac to track this issue better. Could you please try Canary and see if chrome://histograms/ contains a field called Media.Audio.InputStartupSuccessMac, and if so, what it contains.

So far, we have only been able to detect extremely few reports of this and not been able to reproduce locally. 
Project Member Comment 20 by, Nov 6 2015
Hangouts should store logs for all accounts if you have opted in (in the Hangouts settings "Report additional diagnostics..."), but there is a bug (in Chrome and/or Hangouts) that stops this from working sometimes. It's being worked on.
This issue occurs for me in Chrome (not Canary) versions 44,45,46 both Win, Mac and Linux.
Comment 22 Deleted
Project Member Comment 23 by, Nov 6 2015
Labels: OS-Mac
Status: Started
Project Member Comment 24 by, Nov 6 2015
Re #21, are you saying that you can't reproduce in Canary or that you have not tried Canary yet? If the latter, please try Mac Canary as well since we have added more stats to monitor this issue there.

Again, this issue focuses on Mac OS X since that's where we know that there are unique issues related to failing
input audio.
Actually comment #10 described same symptoms as I described in
Project Member Comment 26 by, Nov 18 2015
Analysis in Chrome has shown that the rate of this issue has gone done to very low levels in Mac OS X 10.11. Hence, an upgrade is recommended for any user who experiences this issue.
Project Member Comment 27 by, Dec 1 2015
Labels: fixit
Project Member Comment 28 by, Dec 1 2015
Labels: -Pri-2 Pri-1
Project Member Comment 29 by, Jan 27 2016
 Issue 5175  has been merged into this issue.
Project Member Comment 30 by, Mar 24 2016
Henrik, any update on this issue?
Comment 31 Deleted
Project Member Comment 32 by, Apr 4 2016
Labels: -fixit
Several changes have been done in Chrome (see to combat this issue but no definite solution exists yet. Using Canary will at least ensure that all the latest changes are included and reports from that version are appreciated.

We have been able to reproduce similar issues (using other test methods) by trying to make a WebRTC call directly after resuming from a long power sleep (hibernation). It seems like the Core Audio layer can sometimes end up in state (after long sleep) where it is not possible to resume the input audio session. So far, no other solution has been found to leave this "bad state" but to restart Chrome. Work is still in progress.
Project Member Comment 33 by, Apr 13 2016
Very recent changes shows promising results in Chrome Canary (52.0.2705.0) on Mac OSX.
Any user who still experiences this issue, please use latest Canary and report feedback. Thanks! 
Comment 34 Deleted
We're seeing this a lot in 50. Much higher rate than in 49.
Thanks for feedback xander.dumaine@. A long list of changes have been done to combat this issue and we
are now finally seeing some improvements. It starts at 52 but it can't be merged back to earlier versions due to the combined complexity of all the recent changes. It would be great if you could try latest Chrome as well.
Comment 37 Deleted
Comment 38 Deleted
Confirming large failure rate in Chrome 49, especially on Windows and on Mac as well. I know this thread is about OSX, but anyway. Not much info on Chrome 50 so far.
Project Member Comment 40 by, May 2 2016
igor.pavlov@: which client is utilized? Any other details worth mentioning that can be of help (type of mic, etc.). 
I am sharing the information collected from my customers, so that's the only info I have.
upd: the stats I collect now show mic failures in Chrome 50 as well. What is more interesting, one customer had problems with mic in Chrome 50, switched to Opera 37 and the mic problem was still presented (PC, Windows). I know this thread is about OSX, but it might be useful to know as both Chrome and Opera are chromium-based.
Re Comment 42: as stated in Comment 36, 52 is required to see any improvements in this area. We know that 50 has issues. Everything is not resolved in 52 but the stats looks promising at least.
Project Member Comment 44 by, Jun 21 2016
We have received some positive feedback related to this issue lately but I would appreciate if more users added their experience as well using M52 or later. Thanks.
Comment 45 by, Aug 3 2016
Bad news @henrika.   It happened today to a user with Chrome 52 (OSX 10.11.6).
ggb: Do you know if that user was running beta or stable?  The reason I ask is because 52 is now on stable but if that user was running beta, it indicates a long period since Chrome was restarted and likely a lot of standby/hibernate/resume cycles.  Those patterns seem to affect the audio layer in OSX which eventually causes these sort of issues.

We do have a plan to tackle specifically those sort of problems, but it's going to be a while before we get the benefits of that plan.
We have lots of users running 52 in stable for long periods of time (long running chat + webrtc app) and we're consistently running into this problem. We're having to tell users to restart their app periodically (it runs in both Chrome and in CEF with Chromium 52).
Comment 48 by, Aug 4 2016
tommi: I caught one on Chrome/52.0.2743.82 -- is that beta or stable?
Project Member Comment 49 by, Aug 9 2016
We believe that there's an issue in Mac's audio layer.  It seems that after a number of standby/resume cycles, with audio being used occasionally, that the audio stack can get into a state whereby accessing the microphone seems to work (APIs do not return an error), but we actually do not get callbacks with audio data.  As far as we know, the only way for an application to work around this bug, is to restart the application (and thus reset the client side audio stack state).

We're working on a solution to this by forking Chrome's audio stack out from the browser process and into a recyclable media process.  This is a rather complicated operation though, so it will take time. Unfortunately, it also happens on Windows with almost the same rate as on Mac.
Comment 51 by, Aug 12 2016
#50: yes... i've sent tommi a bunch of data already but good to have another confirmation!

tommi: #49 is just the kind of comment I would like to see much more often. We appreciate that things are hard to fix, but letting us estimate how much effort it is increases our ability to plan. Or to workaround.

And now a way to detect this (which still works in M52 where all the -1 stats are gone, thanks ggb for showing me this trick):

pc.getStats(null).then(function (result) {
  Object.keys(result).forEach(function(id) {
    var report = result[id];
    if (report.type === ‘ssrc’ &&
        report.mediaType === ‘audio’ &&
        parseInt(report.bytesSent, 10) === 0) {
      // show a warning
Project Member Comment 52 by, Aug 12 2016
Thanks fippo, that's useful.

Re #50: Thanks for the info.  The approach we're taking, is intended to target Windows as well.  Just to be sure, do you know if restarting the browser will address the problem you've seen on windows?
Project Member Comment 53 by, Aug 15 2016
Thanks for all new feedback here. We have really tried to come up with solutions that would avoid the issue but as tommi@ mentions, the only real long-term solution is most likely to break out audio-related components into a separate process to ensure that it gets restarted more often.
Are there any manual actions which will fix the issue with a high chance (even temporary) that we (software developers) can suggest to our users (customers)?
Comment 55 by, Aug 15 2016
#54: restarting the browser. You can use the code shown in #51 to know when that is required. One should probably also check if id.indexOf('_send') !== -1 to apply the logic only to the local microphone :-)
Well, we already perform several checks on the microphone and also suggest some actions for windows/mac users. However, none of those suggestions have 100% chance of issue fixing. So as WebRTC team must have been collected new data and the issue now looks like to be isolated, I ask which actions we might want to suggest to users to fix the bug even temporary (ex. to kill some processes, restart a browser, plug/unplug mic etc...)
Comment 57 Deleted
@51 does that implementation of getStats workaround still work?
Trying to use this, I get back an empty results object
or when I do get it back, it does not have those 'type', 'mediaType', etc keys.

Do those only appear when the issue occurs? 
 Issue chromium:648316  has been merged into this issue.
Project Member Comment 61 by, Oct 10 2016
What's the current status of this? Is any more work planned to be done here?
Project Member Comment 62 by, Oct 10 2016
No more work planned currently. The only real viable long-term solution is probably to move the audio parts into a separate audio 
process since that would avoid the very long audio sessions (including sleep/hibernation) that can take place today.

+olka for references to the work on moving the audio parts.
We implemented the solution prescribed in #51. It works for us reliably.
Project Member Comment 65 by, Oct 25 2016
Components: Mic
Comment 66 Deleted
This is a top priority issue for us. As mentioned in comment 62, there's a lot of work needed to fix this fully, but it is in the top 3 issues we are focusing on for desktop.
Project Member Comment 68 by, Nov 7 2016
Reassigning to olka@ who is driving the activity mentioned in #62.

FYI; "Audio stops working on OSX and requires a browser restart to fix" ( describes similar
issues for the output audio in Chrome on Mac.
Pleased to see that this issue is being taken seriously. Is there any estimate of when fix will likely be available? I see this issue regularly so would be happy to beta test. If it helps I tend to have a large number of tabs open >30 and was wondering whether this was due to a memory leak. I also note that resuming from suspend reasonably regularly sees 100% CPU usage and sometimes settles down, but if it doesn't then only restarting Chrome fixes the problem.
Project Member Comment 71 by, Dec 12 2016
Blockedon: chromium:672469
No idea why I am no longer seeing this issue given that the proposed solution has not yet been developed / deployed. Have there been any other updates to address the issue?
Project Member Comment 73 by, Dec 12 2016
Have you had audio driver updates?
Comment 74 by, Dec 12 2016
 Issue chromium:668462  has been merged into this issue.
Not that I am aware of. Unless there have been updates in latest Sierra release (I'm on 10.12.1).
Project Member Comment 76 by, Jan 4 2017
I've been running tests that repeatedly open/verify received audio/close the mic (about 16 concurrent track instances each time) for about 24 hours now with many standby/resume cycles as well as using other apps that use audio at the same time. So far I've not hit the issue.

If anyone has hints about how to get this problem to occur, any help would be appreciated.
Comment 77 by, Jan 11 2017
May we have an update on this issue? While our work around is that we may detect the problem and ask our users to restart their browse, most of them simply abandon our apps. This is not good!
Project Member Comment 78 by, Jan 11 2017
hung@ sure this is not good.
We are taking the issue very seriously. Our team is working on moving audio to a separate process. This is quite a big architectural change and a lot of work.

Help on answering #76 is highly appreciated.
Project Member Comment 79 by, Jan 11 2017
One thing we have discovered is that getUserMedia can in some cases report success even if starting the audio source failed.  In those cases, the media stream object given back by getUserMedia will have an audio track but no audio will actually stream from that track.

A first-step fix has landed towards addressing the problem and is available in Chrome Canary.  The way this fix works is that the state of the audio track will transition to 'ended' (the track's onended event will fire) after getUserMedia reports success.

The second change that fixes the behavior of getUserMedia to fire an error when this happens, is being reviewed this week and will hopefully land before the end of the week and be included in version 57 of Chrome.

This won't address all problems in this area of course, but it addresses a couple of the findings we've discovered thus far and as olka@ says, we're working on a longer term solution to address audio device issues that originate with the OS itself.
Hi - I can report a very consistent situation with a similar problem.

Mic appears to be active as indicated by Ubuntu system settings/sound tab.

getUserMedia returns a stream when I connect the mic in my web app.
Snippet below:

      .then(function (stream) {
        var audioTracks = stream.getAudioTracks();
        if (audioTracks.length === 1) {
          audioTracks[0].enabled = true;
          var context = new AudioContext();
          var mic = context.createMediaStreamSource(stream);
          var debug = context.createScriptProcessor(1024, 1, 1);
          debug.onaudioprocess = function(event) {
            ... meter animation ...
          var destination = context.createMediaStreamDestination();

          var pc = new RTCPeerConnection(msg.config, pcConstraints);

I seem to get data from the mic. As far as I understand there actually is data since I visualize that in the browser with a "meter" animation. 
The meter is responsive in accordance to actual audio level near the mic.
Also chrome://media-internals "audio tab" / input controllers / Controller / show volume = 0.9411764705882353.

The data is then fed to peer connection and it is seems some data is successfully sent. 
I.e. webrtc-internals show bitsPerSecond > 0 BUT audioInputLevel == 0.
See attached jpg image.

Data is actually received by the peer (in this case I'm using Android API -- slightly modified to be able to inspect the data). 

When the audio data is received at peer and after decoding the samples are all zeros.
I inspect the data when it is about to be fed into WebRtcAudioTrack::writeOnLollipop.
Variable speakerMute is false (I call setSpeakerMute(false) from my app - I can confirm from the logs too).
I've tried sample data also before speakerMute-check with same negative result.

Audio and video in other directon is able to play in chrome without problem.

Possible sources of zero samples (just speculation)

1. chrome browser webrtc implementation just before encoding.
2. chrome browser webrtc audio encoder
3. android webrtc lib audio decoder
4. WebRtcAudioTrack implementation
5. My mistake / faulty understanding somewhere


Linux/Ubuntu 14.04
Chrome Version 55.0.2883.87 (64-bit)
Android lib is built from source synced Nov/Dec. 2016
USB mic audio-technica AT2020USB+

I host my web-app on localhost (access it with http://localhost:port).
The peer is also hosted on the very same machine.
123 KB View Download
I think you should file a separate issue for you problems since the original issue is well know and for Max OS X only.

Your issue seems much more complicated and it involves desktop Linux, an Android client and a USB mic. Please try to simplify and isolate more as well.

E.g. does work on both sides.

Did the second change mentioned in #79 made it to Chrome 57?
Project Member Comment 84 by, Mar 17 2017
This issues is consistent for most of our users in Mac OS. Mine is on Mac Caption

Just for a record and update to this thread.

Which version do you see lastly?
Chrome 56 & current 57.0.2987.110

Can you replicate?
Yes, Mostly when we put Mac in sleep or hibernate for a long time.

What other applications fails?
Hangout, Google Voice, Google voice search, Apprtc and all webrtc related connections.

What do you see in chrome://webrt-internals?
bytesSent=0 and audioInputLevel=0

I have to kill all running chrome instance and then start back chrome. even Incognito will fail.

I still have one of my colleague's machine affected in v57. I've told him not to close the browsers so i can collect samples if needed. 

@olka, I really appreciate webrtc chrome team for a long term fix.

Screen Shot 2017-03-22 at 7.18.15 PM.png
201 KB View Download
Project Member Comment 86 by, Mar 24 2017
If it happens again, could you please try (instead of restarting Chrome):

- open a terminal window
- sudo killall coreaudiod

and see if it helps.
@henrika, Today we had this issues on google voice search and we tried 'sudo killall coreaudiod' on mac terminal. 

1. Yes it killed coreaudiod
2. Tried google voice on the same affected browser tab and it works good.
I had the issue again today (mic not working in chrome). Was in a hangout. I killed coreaudioid and mic still did not work in existing hangout session, so ended the call and setup again and mic worked. So a much better workaround than restarting chrome! But of course will be even better when no workaround required.

BTW I normally use as quick check before hangout or other tools that use mic.
Project Member Comment 89 by, May 24 2017
Project Member Comment 90 by, May 30 2017
In wait for a solution of this problem:

I have added a detection in Chrome[1] for the case where the OS doesn't provide any data callbacks, although the input stream seemingly was started successfully or we actually got callbacks to begin with but it stopped after some time. After around 15 seconds of no callbacks, the audio track will be stopped and the ended event is fired in the Javascript world. The reason for the pretty long time is that starting can be deferred on Mac with 5 seconds if we're resuming from standby, plus we have stats reporting after another 5 seconds.

The application can choose what to do, for example try to restart the input stream (maybe just once) and/or inform the user that there is a problem and some workaround is required to solve it, e.g. restart the browser.

This change will be in M60.

grunell: you might want to send a short PSA to discuss-webrtc. The change sounds reasonable and is somewhat preferable to the getStats-based detection which requires a peerconnection \o/
Having the detection logic for the presence of audio is a great step.  Can we add a similar callback for video too.  We are experiencing a similar issue with video data not coming through as well.
Project Member Comment 93 by, Jun 1 2017
#92 - file a feature request and assign the Video component.
Project Member Comment 94 by, Jun 1 2017
Re comment #91: I'll post a PSA to discuss-webrtc.
Project Member Comment 95 by, Aug 14
Can we get an update on the current status for this bug?
Project Member Comment 96 by, Aug 17
We're attacking this from several angles, and have many tasks in progress including trying to collect relevant debugging data when this happens, code inspection/review, code changes to launch as Chrome finch experiments, and more. It's a long term project to figure out why CoreAudio sometimes gets into a bad state and fix it.
henrikg: does your "onended" only trigger ~15 seconds after the stream is returned by getUserMedia or after 15 seconds of no data at any time? I'm trying to figure out how to avoid confusing the event with "you unplugged your microphone".
Project Member Comment 98 by, Aug 24
It's triggered at any time.

I make calls from gmail and I have this same problem occasionally.

Using Mac OSX Sierra 10.12.6 (16G29)
Chrome Version 60.0.3112.101 (Official Build) (64-bit)

Tested on

When this problem happens, I always run this command which fixes it sometimes: sudo kill -9 `pgrep VDCAssistant`

That command has been working less frequently recently (not sure when it stopped being reliable).

This time, I went and captured screenshots then tried "sudo killall coreaudiod". This fixed everything.
Before - InputStartupSuccessMac.png
39.7 KB View Download
Before - midi.png
120 KB View Download
Before - WebRTC ssrc.png
63.0 KB View Download
After - InputStartupSuccessMac.png
38.0 KB View Download
Also has a note, I'm a developer and I'm happy to try any troubleshooting to help resolve this issue
Thanks taubers@, that's interesting!
It looks like in your case Chrome failed to open the device, but application did not report that.
Do you have the same browser session running still? Could you add Media.InputErrorMac histogram here?
Could you also attach the log from chrome://media-internals? 
Project Member Comment 102 by, Aug 25
I believe a failure recorded in the Media.Audio.InputStartupSuccessMac metric as we see here means that we didn't get any callback within the first 5 seconds after starting. So it could have started (and probably did start) successfully. Still please add Media.InputErrorMac, that's good to check.
Project Member Comment 103 by, Aug 25
taubers@: thanks for offering your help!

If you or anyone runs into this case where nothing gets the audio back and restarting Chrome or the coreaudio daemon (i.e. by killing it) would be the only remedy, it would be great if you could do the following to collect debugging data.

Sample the CoreAudio process
1. Open Activity Monitor (Command + Space, type “activity”).
2. In View menu, select “All processes”.
3. Search for “coreaudiod” (upper right).
4. Mark it and select “Sample Process” using the "wheel icon" menu (upper left).
5. Click “Save...” (upper right), provide file or share privately.

Sample Chrome’s browser process
1. Find the Chrome process id:
  a. In the Chrome menu (three vertical dots in upper right corner), More tools > Task Manager.
  b. Note the Process ID of the “Browser” task.
2. Sample the process as described in “CoreAudio process sample” above, but search for “chrome” and select the process with the correct id.

Crash Chrome
1. Go to Settings, show advanced settings, enable “Automatically send usage statistics and crash reports to Google”.
2. Copy and paste chrome://inducebrowsercrashforrealz in the address field and press return. Browser will crash.
3. Start browser again.
4. Go to chrome://crashes, verify that the crash is on top of the list (check timestamp), click “Send Now” to upload the crash dump.
5. When uploaded, provide the Uploaded Crash Report ID.

Project Member Comment 104 by, Aug 28
#99 - are you saying "sudo killall coreaudiod" fixed both audio and video?
Uploaded Crash Report ID 0ab6c9c3a0785766 (Local Crash ID: 355ae46d-aa60-4e1a-ac13-9ed87753fdd8)

Here's my crash report and included process samples from the bug
Sample of Google Chrome.txt
250 KB View Download
Sample of coreaudiod.txt
47.7 KB View Download
If anybody had tried to replace AudioUnit with lower level API? Would that help? Had we seek the help from Apple for this?
Project Member Comment 107 by, Aug 31
The AUHAL is the recommended way by Apple and the AudioOutputUnit (AUHAL) unit sits on top of an AudioDevice object. Hence it is Apple's way of removing the need for these lower level APIs. The existing code base has a very large number of users and I don't think it is worth the effort/risk to come up with an alternative implementation at this stage. And yes, we are using every channel available to resolve the issue.
Project Member Comment 108 by, Aug 31
#105 Thanks for your report. Could you elaborate on in what state your were when taking these snapshots. What were the events leading up to this? Did you end up with no playback or did your microphone stop working (or both?).

Some quick notes on the Chrome trace (mostly for the WebRTC team):
- Most of the samples (1757 of 1779) of the audio thread are in SendSimpleMessageWithSimpleReply. IIUC, this is where the thread waits for callbacks from coreaudiod, so it makes sense that most of the time is spent there.
- 14 of the samples go through IOWorkLoop() + 4568. I believe this is the output callback eventually calling into Chrome code.
- 7 of the samples go through IOWorkLoop() + 4237. I believe this is the input callback. This makes sense both from disassembly and just logically: in a combined input and output callback, as is possible on Mac, you'd want to first give the AudioUnit the input audio to allow that audio to be manipulated before being sent out to the next AudioUnit (or back to the sound card, for example).

So I think we are seeing both input and output callbacks and the thread seems to be running along nicely.
Project Member Comment 109 by, Sep 4
Labels: Needs-Feedback
I reproduced based on Electron.js framework which embedded Chromium inside and did sample with it, would that useful for this problem? I found that in the case, there is only one thread was created. In normal case, 2 threads were created, one for input and one for output.

127 KB View Download
Comment 111 Deleted
Project Member Comment 112 by, Sep 6
More detailed and extended data collection instructions have been posted here:

It includes instructions on how to verify that it's likely this particular bug you're running into.
Project Member Comment 113 by, Sep 7
Re #110: thanks for the input, I'll take at the sample. Generally we'll concentrate on Chrome.
Encountered this as well: 
Uploaded Crash Report ID 7166261cc588307d (Local Crash ID: 10564b75-953a-441a-8f18-cd92d0ce433b)

Sample of coreaudiod.txt
51.4 KB View Download
Sample of Google Chrome.txt
179 KB View Download
I could not sample the coreaudiod process. It would just 'sample' indefinitely. I even tried canceling and trying again.

Uploaded Crash Report ID 3c60bc07d87db031 (Local Crash ID: 68d0fbd2-7cd4-4974-be48-c4e82edde52a)

1. Which direction of audio was missing? Input/mic (others can’t hear you), output/speaker (you can’t hear others), or both.
Input/mic fails. Output/speaker is fine.

2. The audio device(s) used when the problem appeared.
Default macbook pro microphone and speaker.

3. Operating system and version.
macOS Sierra 10.12.6 (16G29)
MacBook Pro (Retina, 15-inch, Mid 2015)

4. Chrome version (chrome://settings/help)
Google Chrome	60.0.3112.113 (Official Build) (64-bit)
Revision	95c454326a7a3153e984e50a4719924968490717-refs/branch-heads/3112@{#744}

194 KB View Download
Hi, I tried doing a one way webRTC broadcasting from my machine, i.e. the camera and speaker of my machine will capture video/audio and sent the data over the Internet. And I hit a problem that Chrome stops sending audio/video data in the middle of broadcast session. Here is the screen shot of the sent audio/video data from chrome://webrtc-internals/ , we can see audio/video bitrate becoming zero midstream. Would anyone help to comment if something wrong with my Chrome? My Chrome is Version 61.0.3163.79 (Official Build) (64-bit) on MAC. Thanks in advance. Here is the debug log detail
Screen Shot 2017-09-12 at 2.17.15 PM.png
455 KB View Download
Screen Shot 2017-09-12 at 2.17.07 PM.png
342 KB View Download
80.2 KB Download
Project Member Comment 117 by, Sep 14
Re #114 and #115: thanks! ossu@ and/or I will take a look.

Re #116: please file a separate bug for this. It sounds like a separate issue or could at least very well be.
I could reproduce the same issue on Chrome 60.
Screen Shot 2017-06-29 at 9.13.28 PM.png
260 KB View Download
The getUserMedia() call was successful and it manages to receive the audio (default microphone) & video (default camera). It seems like when I'm sending my audio to the end user, I noticed the other party could not hear me and when I checked the chrome://werbtc-internals, the recv is missing the (audio) tag but (video) is fine.
Project Member Comment 120 by, Oct 5
Labels: -Needs-Feedback
We have analysed the data we have collected so far (thanks everyone!) and been able to repro, also with a minimal application. It points to being a bug in CoreAudio and a bug has been filed with Apple. We're looking into working around this short-term. Credits to ossu@ for having done the bulk of the analysis work.
Project Member Comment 121 by, Oct 5
aiham@: re #115, are you able to sample coreaudiod when everything works as it should?
What is the status of the Apple bug report? If there's any way I can help, please just let me know!
Project Member Comment 123 by, Oct 16
No update on the Apple bug.

We have landed a workaround in Chrome under an experiment in M63. We'll monitor stats continuously to see its effect.
I'm a developer working on a site that uses WebRTC for audio recording and believe our customers are being affected by this bug. What we are seeing is a large number of Mac Chrome users who are uploading audio which is "empty"/no audio data. We are using the DetectRTC open-source library to ensure that users have a microphone installed and then use the MediaStreamRecorder open-source library for the actual recording (although we just today switched to RecordRTC in place of MediaStreamRecorder for better Safari support).

Anyway, our audience is 48% Windows and 34% Mac. Browser-wise, it's 40% Chrome, 25% Safari, 16% Edge and 9% FF.

80% of the "empty" audio files which we are seeing being uploaded are coming from Mac Chrome users (which you can see is out of sync with overall usage of that browser/OS combination). 23% of our Mac Chrome users have experienced this issue at least once.

It is worth noting that another possible cause of an empty audio file is having the wrong microphone selected in your OS' settings. Even so, that alone wouldn't explain the numbers we are seeing so there does appear to be something specific to Chrome on Mac which is causing problems for our users.

I have a few questions about this bug and the recommended workarounds:

1) Is it confirmed that for the average end user who is not tech-savvy and cannot run terminal commands, simply closing and reopening Chrome will resolve this bug?

2) When this bug is active, is it confirmed that recordings will continue to work in Firefox but not in Chrome?

In the absence of a fix for this issue in Chrome itself, we are forced to direct users to a troubleshooting guide which outlines various steps for the user to take, including those outlined on As pertains to this bug, I included the following in our Help docs:

"There is currently a known issue when using Google Chrome on Mac OS-X which can result in the browser being unable to access the microphone. Among other causes, the bug is triggered by putting the computer into “sleep mode” and then waking it up. If you are using Google Chrome on Mac OS-X and experiencing problems recording, you should close the browser completely and restart it. This should restore the ability for Chrome to access the microphone."

Is everything in that accurate?

The issue is particularly frustrating to me since I use Mac Chrome as my main browser and have never been able to replicate the issue myself. But our site statistics clearly show that something is going on.

Project Member Comment 125 by, Oct 18
Re #124: Yes, for this particular CoreAudio bug restarting the browser is a workaround. The problem is isolated for a particular application, so no other application is affected if it hits Chrome. (Other applications can be hit by this too, but that's independent.) Yes, the bug is triggered by suspend/resume.
I realise a bug has been filed with apple for the CoreAudio bug, would further data provided from the steps outlined above still help with this issue?
Project Member Comment 127 by, Oct 25
Re #126: Thanks for asking. No, we don't need further data at this point.
@127 Is there a link to the apple bug or is it on a private tracker? Thanks!

I have a macbook air (macOS Sierra 10.12.6). 
When i use any webRTC application(hangouts, in-house, gotomeeting, test.webRTC) with chrome the microphone signal is not detected. 
The same works with skype and also within firefox. 
Tried with inbuilt mic as well as by connecting a headset with mic. Still no signal detected.

Here are some details which might help. Hoping this issue gets fixed soon.

I tried restarting chrome, but no change.
Screen Shot 2017-10-31 at 8.54.27 AM.png
36.4 KB View Download
Screen Shot 2017-10-31 at 8.54.54 AM.png
46.0 KB View Download
Comment 130 Deleted
 We’re tracking a similar issue with video recording where we end up with 0kb files. We’ve 1st seen the issue with WebRTC but now we’ve switched to Media Recorder API and we’re still seeing the same issue.

What we’re seeing is that with Chrome on macOS, Media Recorder API’s ondataavailable gets called only once, at the end of the recording (when the uses presses STOP), with = 0. What should happen is ondataavailable should be called about every 200ms with meat in (!=0).

When the user presses record both cam and mic tracks are NOT muted and their readyState is live. With some videos there seems to be sound data (measured through window.audioContext) but with others there is none.

In identifying the issue we now track available devices, used devices, whether or not devices change (plug in a USDB webcam or headset), muted and readyState values for tracks, user agent, average mic gain, time between record & stop clicks (expected length), etc.
@129 can you try to record a video @ .

You seem to be able to replicate the problem consistently. From our observations the issue is inconsistent. The same computer that recorded fine yesterday fails to record today.
In the WebRTC Update 2017 session recorded at the Kranky Geek 2017 event held at Google last friday, Justin Uberti (Engineering lead for WebRTC in Chrome) talks in depth about this issue and the fix that'll be shipped for it in Chrome 63:

The mic input reliability stuff starts at about 10 minutes and 30 seconds in:

There's more talk about solving audio issues at minute 15

It looks like we're finally getting a solid fix for this issue in Chrome 63.

Project Member Comment 134 by, Nov 14
Re #128: The Apple issue is private.

Re #129 and #131: please file separate issues for these.
Project Member Comment 135 by, Nov 14
Blockedon: chromium:160920
Project Member Comment 136 by, Nov 14
I believe most of the issues we're seeing here are caused by chromium:160920. I've added a comment on that bug summarizing our findings and what's being done to fix the issue.

Not sure whether we should dupe this one directly to it, or leave it open as a way to catch other, related errors as well.
Project Member Comment 137 by, Dec 21
Status: Fixed
Closing as fixed now that chromium:160920 is fixed and has made it into stable.
Sign in to add a comment