Open Bug 1896938 Opened 1 year ago Updated 2 months ago

Microphone volume is EXTREMELY low on Mac

Categories

(Core :: WebRTC: Audio/Video, defect, P2)

Product:
Core
Component:
WebRTC: Audio/Video
Version:
Firefox 126
Platform:
Desktop
macOS
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- fixed
firefox128 --- fixed
firefox129 --- fixed
firefox130 --- fixed
firefox131 --- fixed

People

(Reporter: adets, Assigned: pehrsons)

References

(Depends on 1 open bug)

Details

Attachments

(3 files)

RTCPeerConnection Statistics Report
52.45 KB, text/plain
Details
about:support report
76.12 KB, text/plain
Details
mozregression log
169.72 KB, text/plain
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

  1. On MacOS upgrade from Firefox 125 to Firefox 126.
  2. Go to Google Meet or https://online-voice-recorder.com/
  3. Do a recording (or talk on Google Meet).

Actual results:

Recording is of an EXTREMELY low volume, barely audible, even if literally shouting into microphone. Online meetings (aka remote work) are 100% unusable and as a result Firefox can't be used for work and I'm forced to switch the browser - it is impossible to downgrade from 126 (125 just hangs on startup).

Note that in a sense this is not exactly new issue - microphone volume on MacOS was already very low for quite some time (I think since latest MacOS) but there was a workaround documented here: https://www.reddit.com/r/macbookpro/comments/1bjf6st/microphone_very_quiet_on_firefox_only/ Unfortunately, immediately after upgrade to 126 this "media.getusermedia.microphone.prefer_voice_stream_with_processing.enabled" setting doesn't make any difference anymore - it can be true or false, in both cases microphone volume is way, way too low for any practical purposes.

Expected results:

Microphone should capture actual sound instead of virtual silence.

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

Thank you for reporting this issue, if you could provide some additional information and answer some questions that would be helpful in debugging this issue.

  • Could you please open a tab in Firefox and go to about:support to provide that information?
  • While you are seeing the issue navigate to about:webrtc and under RTCPeerConnection Statistics select Copy Report.
  • Are you using a built in Microphone or an external one?
  • Would you be able to test with a Nightly build https://www.mozilla.org/en-US/firefox/channel/desktop/?
  • Would you be willing to run a mozregression https://mozilla.github.io/mozregression/install.html on your system to help identify what change may have caused the issue?
Flags: needinfo?(adets)
Attached file about:support report —
1. Attached `about:support` report. 2. Attached "RTCPeerConnection Statistics" report. Note that this report is not always available, for example, it is available during Google Meet call but not during recording using https://online-voice-recorder.com/ Microphone barely captures anything in both cases.
  1. Attached about:support report.
  2. Attached "RTCPeerConnection Statistics" report. Note that this report is not always available, for example, it is available during Google Meet call but not during recording using https://online-voice-recorder.com/ Microphone barely captures anything in both cases.
  3. Built-in microphone. BTW, I've noticed on about:support page that Firefox shows that "MacBook Pro Microphone" has 3 channels, this looks really strange to me!
  4. Yes, I can test a nightly build and I'll report back. For now I can confirm that issue still exists in version 126.0.1.
  5. I'll try mozregression and report. Note, however, that even before version 126 it was necessary to set media.getusermedia.microphone.prefer_voice_stream_with_processing.enabled=false in order to be able to get recording volume working properly.
Flags: needinfo?(adets)

Tried Firefox Nightly (128.0a1, build ID 20240531213029) on https://online-voice-recorder.com/ and microphone works perfectly, volume is normal!

Attached file mozregression log —

I've executed mozregression in a mode searching for a build that introduced the fix (from 126 release to 2024-05-31 nightly in which everything works) and after a few iterations it reported this:

2024-05-31T23:01:36.381000: DEBUG : Found commit message:
Bug 1404972 - Fix a type of race where AudioCallbackDriver::Start() inits the cubeb stream before tests have hooked up the StreamInitEvent. r=karlt

Differential Revision: https://phabricator.services.mozilla.com/D209474

I've also attached the complete log.

The regression range here points to Bug 1404972 - Use MacOS's audio processing algorithm

Flags: needinfo?(apehrson)
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1894567
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
No longer duplicate of bug: 1894567
Ever confirmed: true
Resolution: DUPLICATE → ---
Duplicate of this bug: 1894567

Thanks for the report, and sorry for the troubles! We've been hooking up macOS's builtin voice processing for mic capture and had our fair share of problems doing so. I'm glad to hear it works in 128!

(In reply to Jim Mathies [:jimm] from comment #9)

The regression range here points to Bug 1404972 - Use MacOS's audio processing algorithm

Yes, well, note that this was the regression range for the fix.

The regression range for the reported volume problem will point to bug 1880244. In particular the vpio-force-list we put in place there due to vpio (even when running in a different process/app) exposing the full mic array of the builtin mic as three channels, and these channels containing very low volume audio, even when mixed. This overrides the prefer_voice_stream_with_processing pref, unfortunately.

Interestingly, a reddit user reports mixing helped -- I'll look into it again.

The original volume issue that was fixed by flipping the prefer_voice_stream_with_processing pref, when did it start? Was it in 122 (bug 1670633)?

More importantly, does the issue come back if you in latest, working Nightly set the media.getusermedia.audio.processing.platform.enabled pref to false?

I have colleagues with M3 macbooks and haven't heard about this from them, so I'm curious. Let's start here and see if we might want to dig deeper later.

Flags: needinfo?(apehrson) → needinfo?(adets)

Also, do you have a recent M3 Macbook like the reddit reports?

(In reply to Andreas Pehrson [:pehrsons] from comment #12)

More importantly, does the issue come back if you in latest, working Nightly set the media.getusermedia.audio.processing.platform.enabled pref to false?

I have colleagues with M3 macbooks and haven't heard about this from them, so I'm curious. Let's start here and see if we might want to dig deeper later.

On Nightly 128.0a1 the issue does not come back when setting media.getusermedia.audio.processing.platform.enabled to false
I have an M3 Pro macbook

(In reply to vasiliirusu+github from comment #14)

On Nightly 128.0a1 the issue does not come back when setting media.getusermedia.audio.processing.platform.enabled to false
I have an M3 Pro macbook

Thanks for the info. This doesn't make sense to me yet. Figuring out the original regressor would be useful, thanks.

I also have this issue in FF127 on M3 Macbook. Changing media.getusermedia.audio.processing.platform.enabled had no effect. Using the latest nightly 129.0a1 (2024-06-13) fixes the issue! Thank you!

Thanks for confirming! Note there were some reports saying forcing mixing of the input channels down to mono helped. Do this by setting the pref media.getusermedia.channels to 1 in <= 126. Note that in 127 the pref changed name to media.getusermedia.audio.max_channels.

The original volume issue that was fixed by flipping the prefer_voice_stream_with_processing pref, when did it start?
I'm not aware as I just got M3 Pro MacBook Pro recently, so for me mic volume without setting prefer_voice_stream_with_processing was broken from the get go.

More importantly, does the issue come back if you in latest, working Nightly set the media.getusermedia.audio.processing.platform.enabled pref to false?

The answer is yes, the issue comes back! Note that it comes back not immediately after setting the property, it comes back after Firefox restart with the new value of the property, it looks like it has no effect on the already running Firefox process. That's why I suspect previous commenters noted that changing the preference has no effect. It definitely has an effect - but only after restart.

Flags: needinfo?(adets)

Tried setting media.getusermedia.audio.max_channels to 1 in Firefox 127, it had no effect - still no mic volume.

Also, do you have a recent M3 Macbook like the reddit reports?

Yes:

  Model Name:	MacBook Pro
  Model Identifier:	Mac15,7
  Model Number:	MRW23LL/A
  Chip:	Apple M3 Pro

(In reply to Alexey Dets from comment #19)

More importantly, does the issue come back if you in latest, working Nightly set the media.getusermedia.audio.processing.platform.enabled pref to false?

The answer is yes, the issue comes back! Note that it comes back not immediately after setting the property, it comes back after Firefox restart with the new value of the property, it looks like it has no effect on the already running Firefox process. That's why I suspect previous commenters noted that changing the preference has no effect. It definitely has an effect - but only after restart.

Thank you for checking this. I'll get my hands on an M3 to reproduce and debug this.

Assignee: nobody → apehrson
Component: WebRTC: Audio/Video → Audio/Video: cubeb

I've tested on an M3 and note the following:

  • It's the builtin mic and when used with vpio in one app, it gets 3 very quiet channels exposed to all apps. One can observe these extra channels in Audio MIDI Setup when using vpio (like Firefox or Safari).
  • Because of those 3 channels we use a force-list forcing vpio with builtin-mic, because prior to the M3 this was enough to get decent volume out of it.
  • With vpio (it has 2 properties to set: bypass and agc) on the builtin mic:
    • Bypass: very quiet regardless of AGC setting
    • No-bypass: volume is fine, AGC setting seems to make a marginal difference.

While fixed in 128 for default constraints (AEC+NS+AGC) it's still broken whenever AEC and NS are not both set.

S3 because not using default constraints is rare, especially with a standard setup like the builtin mic.

Severity: -- → S3

Interesting that the issue was fixed in Firefox 128 nightly builds but in the final Firefox 128.0 release microphone volume is still broken. :-(

Just updated to 128.0 on M3 Max and I am also still having the issue

Can anybody that can reproduce this attempt to flip the few settings that are listed in this ticket and report back if it does anything, in particular media.getusermedia.audio.max_channels, set to 1 ?

(In reply to Paul Adenot (:padenot) from comment #25)

Can anybody that can reproduce this attempt to flip the few settings that are listed in this ticket and report back if it does anything, in particular media.getusermedia.audio.max_channels, set to 1 ?

I was experiencing this issue so far and can confirm that this change appears to have fixed it for me, on my MBP M3 running Firefox 128.0.

Thanks for all the work put into this!

I can also confirm, 128.0 on M3 Max, media.getusermedia.audio.max_channels = 1 worked for me

media.getusermedia.audio.max_channels makes absolutely no difference in my case - no sound from microphone either way (with default 0 or set to 1) on MacBook Pro with M3 Pro with Firefox 128.0. Was working perfectly out of the box with Firefox 128 nightly builds.

In 128, try flipping media.getusermedia.audio.processing.platform.enabled to false, restart, and see if it addresses this.

See Also: → 1908539
Severity: S3 → S2
OS: Unspecified → macOS
Hardware: Unspecified → Desktop

Could someone who is hitting this on 128.0, i.e. with prefs media.getusermedia.audio.processing.platform.enabled=true and media.getusermedia.audio.max_channels=0, please share a logging profile?

To capture the profile:

  • Go to about:logging, select preset WebRTC, click "Start Logging"
  • In a new tab reproduce the setup of the audio input stream leading to the stream having low volume
  • Back on about:logging click "Stop Logging"
  • In the new tab that appears with the Firefox Profiler, in the top right corner, click the button to upload the profile. Please ensure to include hidden threads.
  • Share the url to the uploaded profile here

Thanks!

Flags: needinfo?(neofytosk)
Flags: needinfo?(kjjanak)

I don't see right now how the media.getusermedia.audio.max_channels pref could make a difference. What site were you testing on?
If Google Meet then bug 1908539 is likely in play. Not only would it result in echo, but also lower volume like in 127.

(In reply to Andreas Pehrson [:pehrsons] from comment #31)

Could someone who is hitting this on 128.0, i.e. with prefs media.getusermedia.audio.processing.platform.enabled=true and media.getusermedia.audio.max_channels=0, please share a logging profile?

To capture the profile:

  • Go to about:logging, select preset WebRTC, click "Start Logging"
  • In a new tab reproduce the setup of the audio input stream leading to the stream having low volume
  • Back on about:logging click "Stop Logging"
  • In the new tab that appears with the Firefox Profiler, in the top right corner, click the button to upload the profile. Please ensure to include hidden threads.
  • Share the url to the uploaded profile here

Thanks!

I tested on my M3 and found that it didn't work in version 128.0 with the preferences media.getusermedia.audio.processing.platform.enabled=true and media.getusermedia.audio.max_channels=0.

However, after upgrading to version 129.0, it works with the same preferences. There is still an issue immediately after upgrading to 129.0 with the default configuration, where media.getusermedia.audio.processing.platform.enabled=false.

Here's the profile on 129.0:

https://share.firefox.dev/3YBorJ3

Also have this issue. Maybe I can provide some extra information.
It happens on both my M2 and M3 macbook pro.

  • It only happens with the macbook internal microphone. If I switch to an external microphone there is no issue.
  • It does not matter if the external microphone is connected or not
  • When I go into mac sound settings, both mics receive audio (you see input level change when talking) until FF opens a window where the mic is used (eg. google meet). Then the internal microphone has no more input level.
  • FF has access to all microphones
  • I am using FF 129.1 and tried any combination of the two mentioned settings (https://bugzilla.mozilla.org/show_bug.cgi?id=1896938#c31).

The requested profile capture: https://share.firefox.dev/3M67q29

(In reply to Meng from comment #33)

However, after upgrading to version 129.0, it works with the same preferences. There is still an issue immediately after upgrading to 129.0 with the default configuration, where media.getusermedia.audio.processing.platform.enabled=false.

Here's the profile on 129.0:

https://share.firefox.dev/3YBorJ3

This was a working-as-expected case with media.getusermedia.audio.processing.platform.enabled=true I presume?

Which site was this? It seems AGC was not requested.

I am planning a followup bug that I haven't filed yet that should improve this -- to be stricter on what settings the processing constraints can affect in order to avoid platform issues observed with certain combinations of processing configurations.

(In reply to Jorn from comment #34)

Also have this issue. Maybe I can provide some extra information.
It happens on both my M2 and M3 macbook pro.

Ok, I have an M2 Pro MBP and I thought it was all right in these circumstances, but might depend on what you compare to. I have heard more reports for the M3.

The requested profile capture: https://share.firefox.dev/3M67q29

What the profile shows should get addressed by bug 1913932. Setting media.getusermedia.audio.processing.platform.enabled=true might work in the short-term, but beware it may set off bug 1908539. In corner cases where sites request both a track with processing and another without processing for the same input device, you could still get the lower volume once bug 1913932 has fixed the echo for those cases. Google Meet has been observed to do this sometimes (it was the trigger for bug 1908539). Most of those cases should be addressed by the followup bug I mention above.

Depends on: 1913932
Flags: needinfo?(wakenmeng)

(In reply to Andreas Pehrson [:pehrsons] from comment #35)

This was a working-as-expected case with media.getusermedia.audio.processing.platform.enabled=true I presume?

Yes, it works in version 129.0 with media.getusermedia.audio.processing.platform.enabled=true

Which site was this? It seems AGC was not requested.

This is the site I tested: https://online-voice-recorder.com/

Flags: needinfo?(wakenmeng)
Depends on: 1914046

Thanks for the reply Andreas. Indeed I still have the bug with media.getusermedia.audio.processing.platform.enabled=true applied. I'll wait for the fix of https://bugzilla.mozilla.org/show_bug.cgi?id=1913932 to land and report back.

(In reply to Jorn from comment #37)

Thanks for the reply Andreas. Indeed I still have the bug with media.getusermedia.audio.processing.platform.enabled=true applied. I'll wait for the fix of https://bugzilla.mozilla.org/show_bug.cgi?id=1913932 to land and report back.

If so, I think you'll also need bug 1914046 for your use case. If you test a simpler use case, does it work as expected?
Steps for simpler use case:

  • Go to https://jsfiddle.net/pehrsons/7kgvL48e/
  • Check "Audio" (and make sure "Microphone" is selected)
  • Click Start to request to capture a mic, which will be recorded
  • Say something
  • Click Stop, what was recorded will now be played back
Flags: needinfo?(js.luiten)

(In reply to Andreas Pehrson [:pehrsons] from comment #38)

I tested it in your fiddle. The same thing happens; As soon as I press Start, the volume becomes very low. I also observe an echo.
If it helps you I can make a screen recording of the issue and share it through file.io or something.

Flags: needinfo?(js.luiten)

Just went ahead and made a screen capture. This is on my m3, Sonoma 14.3. You can see and hear what happens to audio input as soon as FF start recording. Hope it helps: https://file.io/XaxQshcnZOWA

Sorry about the echo, I've updated the fiddle so it shouldn't echo any more.
I didn't catch the file, could you upload it again? Or feel free to email it or a link to me directly.

I'll note though, if it's noticeable in a screen capture without the echo and while recording, that audio must be captured through something else.
If that something else is also having low volume the problem is out of our hands; please direct this feedback to Apple. I have previously filed this with them as FB13697689.

I have described this problem a bit here.

Note that Safari and other built-in macOS apps, like Facetime, behave the same.

Flags: needinfo?(js.luiten)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:kinetik, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(kjjanak) → needinfo?(kinetik)
Status: REOPENED → RESOLVED
Closed: 1 year ago → 10 months ago
Flags: needinfo?(neofytosk)
Flags: needinfo?(kinetik)
Flags: needinfo?(js.luiten)
Resolution: --- → WORKSFORME
Depends on: 1908539
No longer depends on: 1914046
See Also: 1908539 → 1914046
Depends on: 1914046
See Also: 1914046 →
Duplicate of this bug: 1922313

Not sure why this issue was closed, it is certainly still not fixed in most recent Firefox 131.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

I'm the original opened of the issue and it is still very much the issue. As I wrote, this was fixed in the nightly build of Firefox 128 but it was broken again in 128 release and never ever fixed since. No, no any unusual configuration. Default built-in microphone, MacBook Pro with Apple M3 Pro, MacOS 14.6.1.

On https://online-voice-recorder.com/ the volume is extremely low, virtually silence.
On https://jsfiddle.net/pehrsons/7kgvL48e/ the volume is low but significantly higher, nowhere near normal level though.

Using Safari or Chrome volume is normal and several times higher than on https://jsfiddle.net/pehrsons/7kgvL48e/ .

I have the same machine as Alexey and also experiencing the exact same issue even on the latest version of FF (131.0.2 as of this writing).

The funny thing is, if I have Firefox and the Sound pane of System Settings side-by-side, I can see the microphone levels are just fine until I navigate to a page in Firefox that takes control of the microphone, at which point the level indicator basically stops moving.

I've also had this problem for the past few months. I'm intially very quiet on work calls, gradually getting louder after I have said a few sentences.

It's a really bizarre one that is becoming quite annoying now as people often don't hear me talking for a little while. I am having to change browser for all my work calls or risk repeating myself several times.

MacOS 14.6.1 / Firefox 131.0

I have the same issue; the microphone starts very quiet and gradually gets louder to a normal level. This forces me to use a different browser (Safari) for video calls on Google Meet.

macOS 15.0.1 / Firefox 131.0.3

Just want to add some more info, on my macbook air m3 when turning microphone on, the sound muted for a few seconds. I noticed this when I am listening to music

Technically cubeb related, but we don't have visibility into those bugs from WebRTC. Moving.

Severity: S2 → S3
Component: Audio/Video: cubeb → WebRTC: Audio/Video
Priority: -- → P2

Same thing happening to me on M4 Macbook Pro. I have tried the various suggestions in the reddit thread but haven't been able to sidestep it. My tests at https://online-voice-recorder.com/ are repeatedly very very low volume.

M4 Macbook Pro - Sequoia 15.3.1
Firefox 136.0

Similar to others.

Per various comments in reddit, other bug reports I played around with the following settings (listed is the new setting). These changes did not fix the issue in online-voice-recorder (I will check back after next meeting to see if Google Meet is fixed but I suspect not).

media.getusermedia.audio.max_channels	1	
media.getusermedia.audio.processing.agc.enabled	false	
media.getusermedia.audio.processing.agc2.forced	false	
media.getusermedia.microphone.prefer_voice_stream_with_processing.enabled	false
media.getusermedia.microphone.voice_stream_priming.enabled	false

I was using Google Chrome up to about a week ago so I don't have any direct experience with this issue on older versions of Firefox.

Same here, M3 Macbook pro, Sequoia 15.3.1 . The problem has been there for about a year I'd say.

When I initially got the M3 and had this problem, the trick I used was to create an aggregated audio input with only the macbook microphone in it. It worked probably because there is no input volume control for an aggregated audio input. But at some point (about a year ago) it stopped working.

To reproduce:

  • Play a constant sound (with my phone).
  • Open the sound system control panel, the input level is about half the gauge
  • Click on record on online voice recorder
  • the input level gauge drops instantly to zero, even before allowing/blocking access to the microphone
  • making a loud noise can raise the gauge to 1, maybe 2
  • when closing the online voice recorder tab, the gauge comes back to its original value after a few seconds

No problem with safari/chrome.

Hope this helps.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: