1546872 - Audio devices appear to only be enumerated on content process creation

Status: RESOLVED FIXED

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

Description

[Trevor Rowbotham [:rowbot]]

Browser: Nightly (latest version)
OS: Windows 10 x64, 1809
Sound Card: Creative Sound Blaster X AE-5
Audio Driver: 6.0.105.19, 2018-08-30

While revisiting some old bugs, I discovered that Firefox seems to only enumerate audio devices during content process creation. This becomes a problem when the browsing session hits the maximum number of content processes, which is currently 8, I believe. Each new tab creates its own content process, up to the maximum. When the maximum is reached, assuming the user does not close the first 8 tabs, all remaining new tabs are dumped into the last content process. This means that every tab opened after the first 8 cannot re-enumerate the audio devices without closing every single tab that corresponds with that content process.

If the user has fewer content processes running than the maximum, then opening and closing that single tab will cause the content process to be respawned, thusly, causing the audio devices to be enumerated again. There is a catch to this, as I believe a content process can be reused. Not really sure how things get handled here in terms of resetting it to some sort of default state.

STR:

1. Open 8 different tabs so that you reach the maximum number of content processes allowed.
2. Open https://mozilla.github.io/webrtc-landing/gum_test.html, in a 9th tab.
3. Click on the Audio button.
4. Firefox should now prompt you to select an input device.
5. Note the available input devices.
6. Open the Windows Sound Control Panel and disable one of the input devices.
7. Close and then reopen the 9th tab from step 2.
8. Note that the list of available input devices did not change.

If you repeat the STR, but only open, say, 2 tabs in step 1, then you will notice that in step 8, the list of audio devices has changed to reflect the disabled input device from step 6.

I feel like I did a really poor job of explaining this, so please feel free to ask for clarification on anything.

Comment 1

[Paul Adenot (:padenot)]

Trevor, is this something recent? Alex, can you try to have a look? I'm suspecting something related to your recent patches to cubeb_wasapi.cpp.

Comment 2

[Alex Chronopoulos [:achronop]]

Yeah, we are missing the disable state from the if check in [1]. I try to remember if there is a special reason I haven't included that.

[1] https://searchfox.org/mozilla-central/rev/d143f8ce30d1bcfee7a1227c27bf876a85f8cede/media/libcubeb/src/cubeb_wasapi.cpp#487-489

Comment 3

[Alex Chronopoulos [:achronop]]

Under review: https://github.com/kinetiknz/cubeb/pull/506

Comment 4

[Alex Chronopoulos [:achronop]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a885e5f28d3141921d9235adfdd0b88552e507a2
Bug 1546872 - Update cubeb from upstream to 64aa80f. r=padenot

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a885e5f28d31
Update cubeb from upstream to 64aa80f. r=padenot

Comment 6

[Trevor Rowbotham [:rowbot]]

Thanks for the quick fix. I can confirm that this was regressed in Bug 1527659.

Comment 7

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/a885e5f28d31