Open Bug 1897736 Opened 6 months ago Updated 4 months ago

Microphone input contains DC offset

Categories

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

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

Tracking

()

People

(Reporter: pehrsons, Unassigned)

References

Details

See bug 1890426 comment 7:

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

bug 1890426 comment 10:

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

bug 1890426 comment 12:

Hi Andreas,

In my case, toggling 'prefer_voice_stream_with_processing' doesn't make a material difference to the recording.

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.

And my bug 1890426 comment 14 reply:

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.

Jamie, if you find something with mozregression, let us know. Note that the mozregression-GUI doesn't have mic permissions listed in its Info.plist so won't be able to use getUserMedia. The command line version works as permissions then go via the Terminal app.

Re my comment on downmixing we could try to verify if we can trace that any further by checking if we do any downmixing. For that we need cubeb logs of when the captured audio stream is set up:

  • Go to about:logging, select the WebRTC preset, click Start Logging
  • Reproduce the issue, and include the getUserMedia call
  • On about:logging again, click Stop Logging
  • In the Firefox Profiler tab that appears, upload the profile, and please include hidden threads
  • Share the link to the public profile here

If this indeed does not happen in other apps, it's probably a bug in macOS' aggregate devices, which we use to couple input and output (including drift control) when not doing any audio processing.

We could also dump the audio per-channel as given to us by coreaudio to see if it is really a platform issue, but that requires a custom build so let's save it for when all else fails.

Flags: needinfo?(jamie)

Hi Andreas,

Sorry for the late response getting back to you!

I've noticed as of a recent Nightly update this no longer happens - getUserMedia returns the correct stream again. I'll do mozregression in reverse and try and pinpoint the fix, so we can close off this bug.

We had some reports of this happening from some of our users in the wild, post-release of 128, but they were satisfied with a temporary downgrade to ESR.

Flags: needinfo?(jamie)
You need to log in before you can comment on or make changes to this bug.