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

Issue 4799 link

Starred by 107 users

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

Issue metadata

Status: Fixed
Last visit 22 days ago
Closed: Dec 2017
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

Issue description

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 

Showing comments 38 - 137 of 137 Older

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 2017

Can we get an update on the current status for this bug?
Project Member

Comment 96 by, Aug 17 2017

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 2017

It's triggered at any time.

Comment 99 by, Aug 24 2017


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

Comment 100 by, Aug 24 2017

Also has a note, I'm a developer and I'm happy to try any troubleshooting to help resolve this issue

Comment 101 by, Aug 24 2017

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 2017

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 2017

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 2017

#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 2017

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 2017

#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 2017

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 2017

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 2017

Re #110: thanks for the input, I'll take at the sample. Generally we'll concentrate on Chrome.

Comment 114 by, Sep 11 2017

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

Comment 115 by, Sep 11 2017

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 2017

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 2017

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 2017

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 2017

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 2017

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 2017

Re #126: Thanks for asking. No, we don't need further data at this point.

Comment 128 by, Oct 26 2017

@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 2017

Re #128: The Apple issue is private.

Re #129 and #131: please file separate issues for these.
Project Member

Comment 135 by, Nov 14 2017

Blockedon: chromium:160920
Project Member

Comment 136 by, Nov 14 2017

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 2017

Status: Fixed (was: Started)
Closing as fixed now that chromium:160920 is fixed and has made it into stable.
Showing comments 38 - 137 of 137 Older

Sign in to add a comment