Open Bug 1459736 Opened 7 years ago Updated 2 years ago

Investigate disabling libcubeb's WinMM backend

Categories

(Core :: Audio/Video: cubeb, defect, P3)

defect

Tracking

()

People

(Reporter: kinetik, Unassigned)

References

Details

The WinMM backend (https://github.com/kinetiknz/cubeb/blob/master/src/cubeb_winmm.c) was required for pre-Vista Windows support. We stopped supporting pre-Vista (and Vista) back in Firefox 52, so we should be able to assume WASAPI is available on all supported Windows platforms now. The telemetry for AUDIOSTREAM_BACKEND_USED seems to back this up. We see 98.07% (323 million samples) using the WASAPI backend, 312 samples using the WinMM backend, 0.29% failing to initialize audio at all, and 1.64% hitting an error when initializing a stream some time during the Firefox run time. The 312 samples under the WinMM backend could be caused by explicitly setting a libcubeb backend via the override pref, or via the fallback mechanism when WASAPI is not available (which could be triggered by the lack of an output device even if an input device was present, see https://github.com/kinetiknz/cubeb/pull/436). The WinMM backend is fairly stable and hasn't seen significant changes in a long time but it lacks features necessary for WebRTC (see bug 1221578) and creates an on-going maintenance burden, especially as we work towards remoting/sandboxing audio and reworking the libcubeb backends in Rust. I propose disabling the WinMM backend by disabling it for a release or two by removing fallback to WinMM from WASAPI (with a pref allowing it to be reenabled), then removing the backend and pref from a later release. (As an aside, it looks like we need a better mechanism to diagnose the stream open failures - bug 1289678 was supposed to reduce the count of non-first-stream failures, but we're seeing values higher than when that bug was filed.)
Rank: 20
Priority: -- → P3
It's likely that https://github.com/kinetiknz/cubeb/pull/436 would reduce the WinMM counts somewhat. That fixed a case where we'd give up on WASAPI during feature detection if there was no output device (even if an input device was present), which would then result in falling back to WinMM.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.