Chrome (Windows) Regression: getUserMedia() Using Wrong Default Microphone Causing Low Volume in BigBlueButton

[Latif Ur Rehman]

Hello everyone,

We have recently started experiencing a serious microphone issue affecting users on Windows with Google Chrome. After extensive testing, we believe this is not a BigBlueButton issue, but rather a regression introduced by a recent Chrome update.

Environment

• Platform: Windows 10 / Windows 11

• Browser: Google Chrome (latest version)

• Application: BigBlueButton

• Other Browsers: Microsoft Edge works correctly

Problem

When a user joins an audio session, BigBlueButton selects the "Default" microphone as expected.

However, Chrome appears to resolve the "default" deviceId incorrectly. Instead of capturing audio from the actual Windows default microphone, it sometimes captures audio from another available microphone (for example, the laptop's built-in microphone) or routes audio through an incorrect Windows communications device.

As a result:

• Microphone volume is extremely low.

• Audio sounds distant or muffled.

• Users believe their microphone is not working properly.

Workaround

If the user manually opens the microphone selection dropdown and explicitly selects the exact microphone (using its hardware device ID), the problem disappears immediately.

The same physical microphone then works perfectly with normal volume and clear audio.

Additional Observations

• The issue only occurs in Google Chrome on Windows.

• Microsoft Edge does not show this behavior.

• Android/mobile browsers are also unaffected.

• We tested older BigBlueButton backups and observed the same behavior, which strongly suggests the issue is browser-related rather than caused by recent BBB changes.

Technical Notes

It appears that when Chrome receives:

getUserMedia({ audio: { deviceId: "default" } });

it sometimes resolves "default" to the wrong physical input device or applies incorrect routing/audio processing.

When the exact hardware deviceId obtained from enumerateDevices() is used instead, audio capture works correctly.

Questions

Has anyone else noticed this regression after the latest Chrome update?

If so:

• Have you found a reliable workaround?

• Has this already been reported to the Chrome/WebRTC team?

• Are there any recommended BigBlueButton-side mitigations until Chrome fixes the issue?

Any information or confirmation from others would be greatly appreciated.

Thank you.