Open
Bug 1459736
Opened 7 years ago
Updated 2 years ago
Investigate disabling libcubeb's WinMM backend
Categories
(Core :: Audio/Video: cubeb, defect, P3)
Core
Audio/Video: cubeb
Tracking
()
NEW
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.)
Updated•7 years ago
|
Rank: 20
Priority: -- → P3
Reporter | ||
Comment 1•7 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•