1890426 - Microphone input is overamplified

Status: RESOLVED DUPLICATE of bug 1404972

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

Description

[Capy]

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

Steps to reproduce:

This bug appeared after upgrading mac os to Sonoma 14.4.1 (from monterey). I checked other apps, this issue only appears in firefox.

Step 1) Go to a mic testing website like https://mictests.com/
Step 2) Speak
Step 3) Listen to your recording

Actual results:

Mic input is extremely amplified (it sounds normal only when it is set to -11.99db 0.01% in MIDI settings and sounds extremely bass boosted at 100% / +0db).

Expected results:

It should sound like in every other app (Chromium, Safari, Recorder)

Comment 1

[Ada C.]

Hi, Capy

I managed to reproduce this issue on latest Nightly 126.0a1 (2024-04-12) using macOS 14.4 (Sonoma); I tested against Chrome (v. 123.0.6312.124).
If component is not correct please update. Thank you.

Comment 2

[Andreas Pehrson [:pehrsons]]

If you flip the pref media.getusermedia.microphone.prefer_voice_stream_with_processing.enabled to false on about:config, does it sound like you'd expect?

We've noticed this with some devices as a side effect of using macOS' VoiceProcessingIO audio unit in bypass mode with AGC disabled. I expect bug 1404972 will help here since with it we will by default neither use bypass nor disable AGC.

Feel free to report as feedback to Apple.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1670633

Comment 4

[Capy]

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

If you flip the pref media.getusermedia.microphone.prefer_voice_stream_with_processing.enabled to false on about:config, does it sound like you'd expect?

Yes, it sounds normal. This workaround fixes the problem when it is set to false.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:pehrsons, since you are the author of the regressor, bug 1670633, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[Andreas Pehrson [:pehrsons]]

Could you try if there's an improvement in latest Nightly with the pref reset? Thanks.

Comment 7

[Jamie W]

I observed this today (Nightly 20240502160659) on macOS 10.15. I noticed killall -9 coreaudiod would fix it for a few getUserMedia's.

I'm going to try and find some time to use mozregression to work out when it started

Comment 8

[Andreas Pehrson [:pehrsons]]

Hi Jamie, thanks for the report. Would you have an audio recording of this to share? Also could you elaborate on the steps when you say killing coreaudiod fixed it? Did you kill coreaudiod and call getUserMedia again?

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1670633

Comment 10

[Jamie W]

I managed to reproduce it and, upon closer inspection, it manifests as DC offset.

The audio isn't particularly bass boosted like in the original report, so I'm not fully convinced this is the same issue, but the resulting audio does clip when converted to integers (e.g. 16-bit WAV).

Killing coreaudiod: this is something I often do when multiple apps are audio, to work around an unrelated and long-term coreaudio bug where the built-in speakers crackle. This often makes starting a recording (getUserMedia, opening an AudioContext, etc) much snappier

I develop software using Web Audio APIs in my day job and I use Firefox as my daily driver. This issue is relatively novel as I've only recently started observing it.

I've uploaded a recording from the built-in microphone in a relatively silent room (notwithstanding laptop fans) with DC offset. The recording was made using an AudioWorklet rather than MediaRecorder

https://cdn.index.hm/f/DBkX0zVlOWU1ODg0OTU5N/record-data-2024-05-14T19-48-15.528Z.wav

Comment 11

[Andreas Pehrson [:pehrsons]]

Thanks for the recording. This is the first time I see it behave like that. I imagine the regressor is the same as for this bug although the symptoms may manifest differently. It doesn't sound like a bug on our end since you say killing coreaudiod helps. Feel free to file feedback on CoreAudio with Apple since this also likely is a VoiceProcessingIO audio unit issue. If you can reproduce you may be able to gather system logs that are helpful to them.

For now if you want a workaround in Firefox you can on about:config set the pref media.getusermedia.microphone.prefer_voice_stream_with_processing.enabled to false. And not to forget, if you in your work don't need to worry about echo, you may be better off turning off all audio processing in the getUserMedia request (then we'll also not use the VoiceProcessingIO unit). But beware you might hit the original symptoms of bug 1670633 in either of those cases.

Comment 12

[Jamie W]

Hi Andreas,

In my case, toggling 'prefer_voice_stream_with_processing' doesn't make a material difference to the recording. The DC offset sitting at nearly 0dB does.

The application in question is designed for broadcasters using professional audio equipment and as such it calls getUserMedia with the default enhancements (AGC, echo cancellation, noise suppression) explicitly off. I'm planning to work around this by changing the normalisation code to correct DC offset and to run it before converting the audio into a discrete 16 bit sample where it would clip.

Although it could be that the regression has exposed a long-term bug in coreaudiod, indeed it was the update to Firefox that triggered it, as this Mac is running an old 10.15 release of macOS. Another pattern that's emerged during my testing is it happens every other recording, if the recordings occur within about a minute of each-other, no matter how many times I restart coreaudiod.

Sadly, I've not yet had the free time to use mozregression to confirm if the root cause is the same - but I'll be sure to post an update if I do.

Comment 13

[Jamie W]

(Sorry, I thought I had deleted that last bit of the first paragraph - please disregard it!)

Comment 14

[Andreas Pehrson [:pehrsons]]

(In reply to Jamie W from comment #12)

Hi Andreas,

In my case, toggling 'prefer_voice_stream_with_processing' doesn't make a material difference to the recording. The DC offset sitting at nearly 0dB does.

The application in question is designed for broadcasters using professional audio equipment and as such it calls getUserMedia with the default enhancements (AGC, echo cancellation, noise suppression) explicitly off.

Thanks for this background. If the processing is explicitly off like this we won't use the VPIO audio unit and then this cannot be a bug 1670633 regression. We should be getting pretty raw audio data from coreaudio in this case, modulo potential downmixing that may happen on our end, depending on the device setup. I'll file a new bug, let's continue there.

Comment 15

[Andreas Pehrson [:pehrsons]]

With bug 1895787 fixed and the platform processing from bug 1404972 enabled in 128, could you test latest Nightly and see if there's an improvement?

Comment 16

[Capy]

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

With bug 1895787 fixed and the platform processing from bug 1404972 enabled in 128, could you test latest Nightly and see if there's an improvement?

Just tested the latest nightly, mic sounds good, the bug seems to be fixed. Thanks!

Comment 17

[Andreas Pehrson [:pehrsons]]

Thanks for confirming!