Bug 294623 – MediaRecorder severely reduces input audio volume for all non-Safari apps when recorded simultaneously

• Status: NEW
• Component: Media

[Will Field-Thompson]

Created attachment 475588 [details]
The sample HTML which causes the issue.

Hi! This is my first WebKit bug, so please let me know if there's anything I ought to do differently in the future, or if there's any additional info you need.

# Description
When using the MediaRecorder API to record audio in Safari, all other apps on the system which are recording audio have their input volume substantially reduced to the point that it is very difficult to hear audio recorded in other apps. This does not happen with Chrome or Firefox on the same machine, with the same OS, with the same microphone. The audio recorded by Safari itself is unaffected.

# Usecase
Our webapp helps people practice public speaking and giving presentations. Sometimes these users would like to record in our app while presenting over a video call or practicing with our coaches, also over a video call.

Unfortunately we have to put a banner at the top of the page suggesting users don’t use Safari because using MediaRecorder on Safari makes it so no one can hear them over Zoom (or Teams, or Slack, etc.). Luckily we do have a native macOS app they can use & every other browser works fine, but we’d really like our webapp to match our native app with zero caveats.

# Environment
Every built-in/internal Mac microphone we’ve tested is affected. Some external microphones are unaffected. Example: my Macbook Pro 16-inch, 2023, M2 Pro, 32 GB RAM; using the built-in microphone reproduces every time.

I have reproduced this using the following version combinations:
- Safari 18.5 (20621.2.5.11.8) on macOS Sequoia 15.5
- Safari Technology Preview Release 221 (WebKit 20622.1.15.19.2) on macOS Sequoia 15.5
- Webkit build 296320@main on macOS Sequoia 15.5 from the build archives
- Safari 17.3.1 (19617.2.4.11.12); macOS Sonoma 14.3.1

This affects every audio recording app we’ve tried, including Zoom and QuickTime. My reproduction steps use QuickTime because it’s pre-installed on macOS.

# Reproduction steps
I have attached a reduced HTML example.
1. Open QuickTime Player
2. Click File > New Audio Recording…
3. Use the little dropdown indicator to select the internal microphone (e.g. Macbook Pro Microphone)
4. Start recording in QuickTime and begin speaking. Speak continuously throughout the next few steps, so you can observe the change in volume.
5. Open the sample HTML in Safari
6. Click “Record” and give microphone permission
7. Record several seconds of speech
8. Click “Stop” on the webpage
9. Record several seconds more of speech
10. End recording in QuickTime
11. Listen back to the QuickTime recording, noting that the volume decreases when you started recording in the webpage and increases again when you stopped recording.
12. Listen back to the recording in Safari, noting that the volume there is at a reasonable level

[Radar WebKit Bug Importer]

<rdar://problem/154214161>

[Ahmad Saleem]

@Will - does it affect any live website or service? Just trying to understand impact.

[youenn fablet]

This is the getUserMedia call that is likely triggering audio ducking.
@Will, to prevent audio ducking, could you try `echoCancellation: false` as part of audio options given to getUserMedia?

[Will Field-Thompson]

@Ahmad Yep! It affects our service at app.speeko.co. Relatively early days for this project — we are building this out as an equivalent to our native iOS/macOS apps.

@youenn I edited `getUserMedia({ audio: true })` to be `getUserMedia({ audio: { echoCancellation: false } })` and the results are fascinating (Safari Version 18.5 (20621.2.5.11.8) running on macOS 15.5 (24F74)). The first time I did this, the audio was ducked for a 2-3 seconds, then came back to regular volume (while Safari was still recording). Every time after that (even across reloads), the ducking doesn't happen. If I quit Safari & reopen it, then the initial ducking occurs again.

This is still something I'd like to see fixed (especially since echo cancellation is such a nice feature), but that's a pretty solid workaround for us!