1430907 - Windows Volume Mixer still creates extra volume sliders for content processes

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P5)

Description

[David Parks [:handyman]]

STR:

1. Open sndvol.exe on Windows 10.  (Right-click the speaker in the system tray and select "Open Volume Mixer")
2. Launch Firefox
3. Create a few (usually two is enough) new tabs

Expected Results:
There is only one volume slider for Nightly in the volume mixer

Actual Results:
There are multiple sliders.

----------

This is really the original bug in bug 1358372.  There, we landed a few hacks that reduce the impact of the issue but we still need a fix.  We've reported the problem to Microsoft but it shouldn't be an issue for us anyway once audio remoting lands.  

This bug tracks all that.

Comment 1

[Djfe]

One slider per tab that's playing media/per media element, could also be interesting, but only if Firefox synchronized that slider with the volume slider of the media element. (each slider in the mixer would have the tab's title + the number of active media elements in that tab [1] [2], if there are more than one)
And a general slider ("Firefox") for all other sounds (notifications), that aren't playing at all times.

Just a suggestion. I don't even know, if it's possible to implement it :)

Comment 2

[z1347254]

I'm having the same issue ever since Mozilla quantum was released originally. (Widnows 7 Home prerium x64) No other program does this (Chrome, Discord, etc. all work fine.)

The icons stay in the volume mixer even after shutting mozilla firefox down.
See picture below.
https://i.imgur.com/MRyEGGB.png

Picture was taken after the firefox had been shut down. These icons don't reset untill I restart my computer.

Comment 3

[Djfe]

in which bug is audio remoting being tracked actually?

@z check out your Taskmanager whether Firefox still runs. If it still does after closing it, then you have another bug to report ;)
This one will be fixed overtime, but the sliders don't stay if you close the browser(therefore I guess, that yours is still running in the background).

Comment 4

[taosk8r]

Im having the same issue with win 8.1 x64. FF closed, 5 volume panels still up crowding my freaking volume mixer.

Was going to post I screen shot, but I see no way here.

Comment 5

[taosk8r]

Attachment: This is a picture of the 'phantom' sliders that stay alive after FF is closed.

Comment 6

[smartfon.reddit]

This bug, coupled with another one here: https://bugzilla.mozilla.org/show_bug.cgi?id=1407288

...is causing a significant negative impact on the usability. From my other post:

>

..especially for Bluetooth headset users. I have to constantly open the Volume Mixer and slide Firefox bar lower because it keeps matching to the "Headphones" volume bar. When the Firefox and Headphones are matched, Firefox is so loud that lowering the system volume to "4" is still too loud, while going one bar lower to "2" completely mutes the sound. As a result, the only solution to enjoy any kind of media on Firefox at normal low sound level is to every time open the Volume Mixer and lower the Firefox bar, which then allows making Firefox's sound reasonably low upon using the system volume control at the 4-10 range. 

It doesn't help that there is another bug where Firefox injects dozens of Firefox entries under Volume Mixer. This makes it harder to find the actual slider that needs to be lowered. 

<

Current situation:

1. Use the keyboard to set the Windows 10 volume to "4". Firefox is still too loud. (Windows 10, Bluetooth headphones)
2. Open Volume Mixer. The "Headphones" (aka Windows 10 volume you adjust with the keyboard) and "Firefox" are synchronized.
3. Lower the Firefox volume to half of Headphones.
4. Do something that triggers the volume mixer bug.
5. Play a sound at volume level 4. Firefox is too loud again.
6. Open Volume Mixer and you'll notice the Headphones and Firefox are once again synchronized and at the same level, because Firefox bug created a new Firefox entry under Volume Mixer. The old Firefox entry was un-altered, but now the new one needs to be lowered too.
7. The cycle continues. Dozens of Firefox entries can appear under Volume Mixer, making the previous adjustments useless. Media consumption becomes a problem.

Since this is not merely a cosmetic issue, could you possibly review the bug priority for this and the other volume mixer bug? Thanks.

Comment 7

[Djfe]

it keeps matching to the volumes bar probably because it creates threads.
That is part of this issue.

The rest isn't as far as I can see.

Your issue sounds quite annoying, but you don't seem to be the only one to which it happens.
It's definitely a bug in windows/your bluetooth driver and not in Firefox, the driver doesn't set the volume correctly for some reason.
Here is the workaround that allows you to set the max. volume way lower: https://www.youtube.com/watch?v=vN38FlUiClU

It would be nice if this bug that's actually discussed here, will get fixed one day, yes.
But at least the volume sliders of each video/audio element on a webpage still work. (soundcloud, youtube etc. have their own sliders to adjust the volume after all)
Currently I wouldn't recommend using the sliders in the windows mixer at all.

If you want the volume bug fixed in windows, then you might want to use "Windows Feedback", one of Microsoft's forums or call/mail microsoft's support.

Regards

PS: I'm not working at Mozilla

Comment 8

[smartfon.reddit]

Now that you've mentioned threading, I recall another issue. There was another reproducible problem with the Bluetooth audio stuttering (persistent stutter as if 1 FPS, would not go away until adapter reset) after interacting with a video playback on Firefox. Sysinternals Process Monitor showed that at the time when stutter would start, Firefox would create/close threads. When I pause/play a video the browser would create/close threads according to Sysinternals. Is this normal? I've since managed to solve the problem by doing multiple re-installs and the finally installed Firefox 62 Beta, and the solved the Bluetooth stutter for now. I was not having the Volume Mixer duplication problem back then.

Now, it's having the Volume Mixer duplication issue, but not the Bluetooth audio stutter. Is that the OS that's responsible for creating threads for Firefox and it's something that can only be fixed by Microsoft? I ask because if a Mozilla employee filed the bug with Microsoft, that could get us somewhere, wheres a Windows 10 Feedback report most likely won't yield any results if submitted by an ordinary user.

Comment 9

[Djfe]

I have no clue, but the issue you had is fixed in newer Firefox versions (somehow), so you also can't reproduce it anymore.
and this bug report isn't about this issue.
If you feel, that there is still something that needs to be solved, then you might as well open another bug report for that ;)
(we should keep this issue clean :))

Comment 10

[dave.wedd]

I've just updated Firefox (to 63.0) and I'm now seeing this bug for the first time.  I haven't used any webpage that would use audio, yet I now have 6 Firefox or Mozilla Firefox items showing in Volume Mixer.  When the first two appeared I muted them, and the muting has now appeared on all the additional copies.

Windows 10 (1803) on Dell Inspiron N7710 with 6GB RAM.

Closing Firefox leaves all the instances in Volume Mixer.  Interestingly, after looking at the Firefox About to see the version number, the third of the instances is now called "Console Window Host" with a Firefox logo.  Opening Firefox again has created two more instances - so I now have 8.  Looking through Task Manager I can't see anything running with a Firefox logo.

Other programs like VLC Media Player are creating a single instance in Volume Mixer and correctly disappearing as soon as they are closed.  Chrome doesn't even appearing since it isn't needing to use audio.

Comment 11

[barrelrollmais]

This bug affects me as well. I'm on firefox 63.0.3, on windows 10 (1803) and on a . Firefox icon's dont dissapear, which leads in my case to about 10 identical firefox sliders in the windows volume mixer. Impossible to tell which one corresponds to the live firefox.

Comment 12

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: volume_mixer.png

I had19 entries for Firefox in my Volume Mixer (perhaps some are from a closed Firefox instance and some are from the active Firefox instance). I'm on 65.0a1 2018-12-08 64-bit, Windows 10.

However, a short time later, I'm back down to one: it's unclear what changed.

:Jimm, can you elaborate on why this prioritized as P5? When this bug occurs, it makes the Windows system less usable.

Comment 13

[Dan]

Same here, occurs often now when different Firefox installs are being used at the same time.

Comment 14

[mb]

As a workaround until this gets fixed, W10 users should try out Eartrumpet [1], its more intuitive than Windows' volume mixer.

[1] https://www.microsoft.com/en-us/p/eartrumpet/9nblggh516xp

Comment 16

[Dan]

intuitive, yes, but Eartrumpet volume overview also always opens in upper left corner of screen instead of last position at moment of closing. :/

Comment 17

[kovitikus]

Hello?
taps the microphone
Is this thing on?

https://i.imgur.com/8BVdG3z.png

Comment 18

[kovitikus]

Attachment: This is getting out of hand. Now there are 23 of them.

Comment 19

[Matthew Gregan [:kinetik]]

This is fixed in current Nightly builds.

Comment 20

[Dan]

Nope, not for me...

Comment 21

[Matthew Gregan [:kinetik]]

(In reply to Dan from comment #20)

Nope, not for me...

It'd be helpful to provide more information. What is the build ID of the Nightly build you tested?

Comment 22

[Dan]

still occuring on 20200221214911. I open a new tab (YouTube), a new slider is added.

Comment 23

[Matthew Gregan [:kinetik]]

(In reply to Dan from comment #22)

still occuring on 20200221214911. I open a new tab (YouTube), a new slider is added.

If you check about:config, is media.cubeb.sandbox set to true?

Comment 24

[Mikael Håkansson]

Have seen two posts on Reddit recently where people with older version of Windows 10 (1809) still have this bug, never seen anyone with this on a newer version of Windows 10.

Dan, is your Windows 10 version 1809 or older than 1909? Right click Start menu > System.

Comment 25

[Dan]

yes set to true. yes, I'm on 1903.

Comment 26

[Matthew Gregan [:kinetik]]

Note that sndvol seems to continue displaying unused/dead volume controls for some time after they're unused (possibly until sndvol is restarted?). If I leave sndvol open and restart Firefox, I can see two Firefox volume control entries... but only one is used, and restarting sndvol shows only a single Firefox volume control remains.

Comment 27

[David Parks [:handyman]]

Looks like Bug 1432303, which covers audio (cubeb) remoting on Windows, is now landed in trunk. I believe this means that we no longer need to generate sound from the content process. If so, we can stop initializing an AudioSession in content processes, which should make this problem go away (save, possibly for a volume control for Flash use in the plugin process). I'm going to try that and see what happens.

Comment 28

[David Parks [:handyman]]

Attachment: Bug 1430907: Part 1 - Remove AudioSession from Windows content process r=kinetik

AudioSession, which handles things like making sure that the volume slider in the system tray has the right name and icon and is aligned for all processes, is not needed in content processes any longer since bug 1432303 remoted audio use away from content.

Comment 29

[David Parks [:handyman]]

Attachment: Bug 1430907: Part 2 - Use Windows Event to signal death of monitor_device_notification thread r=kinetik

We are running into some dangeous internal locking behavior in _endthreadex when shutting down the monitor_device_notifications thread in Windows Audio IPC. To avoid deadlock, this patch uses its own Windows Event to synchronize the death of that thread with the Audio IPC Server thread that governs its shutdown.

Depends on D64445

Comment 30

[David Parks [:handyman]]

Removing the AudioSession from content processes fixes this issue. In trying out a bunch of audio stuff, I regularly hit a cubeb IPC hang at shutdown. I wouldn't be surprised if this is the cause of Bug 1610640. I suspect it's related to (but not the same as) this [1]. The deal for me is that the "Audio IPC Server RPC" thread is doing this:

  ntdll.dll!NtWaitForSingleObject()  Unknown
  KernelBase.dll!WaitForSingleObjectEx() Unknown
  xul.dll!monitor_device_notifications::~monitor_device_notifications() Line 352  C++
  [Inline Frame] xul.dll!wasapi_collection_notification_client::~wasapi_collection_notification_client() Line 511 C++
  xul.dll!wasapi_collection_notification_client::~wasapi_collection_notification_client() Line 511  C++
  xul.dll!wasapi_collection_notification_client::Release() Line 483 C++
  [Inline Frame] xul.dll!`anonymous namespace'::com_ptr<wasapi_collection_notification_client>::release() Line 167  C++
  [Inline Frame] xul.dll!`anonymous namespace'::com_ptr<wasapi_collection_notification_client>::~com_ptr() Line 123 C++
  [Inline Frame] xul.dll!cubeb::~cubeb() Line 189 C++
  xul.dll!`anonymous namespace'::wasapi_destroy(cubeb * context=0x00000212e34d9b80) Line 1581 C++
  xul.dll!core::ptr::real_drop_in_place<audioipc_server::server::CubebContextState>(audioipc_server::server::CubebContextState *=0x00000059e14bf4c8) Line 175 Unknown
  xul.dll!std::thread::local::fast::destroy_value<core::cell::RefCell<core::option::Option<audioipc_server::server::CubebContextState>>>(unsigned char * ptr) Line 470  Unknown
  xul.dll!std::sys_common::thread_local::register_dtor_fallback::run_dtors() Line 257 Unknown
  [Inline Frame] xul.dll!std::sys::windows::thread_local::run_dtors() Line 234  Unknown
  xul.dll!std::sys::windows::thread_local::on_tls_callback() Line 205 Unknown
  ntdll.dll!LdrpCallInitRoutine() Unknown
  ntdll.dll!LdrpCallTlsInitializers()  Unknown
  ntdll.dll!LdrShutdownThread() Unknown
  ntdll.dll!RtlExitUserThread()  Unknown
  kernel32.dll!BaseThreadInitThunk() Unknown
  ntdll.dll!RtlUserThreadStart() Unknown

while the monitor_device_notifications child thread is hung in _endthreadex, which is implicitly called when the thread function thread_proc is exited:

  ntdll.dll!NtWaitForSingleObject()  Unknown
  ntdll.dll!LdrpDrainWorkQueue()  Unknown
  ntdll.dll!LdrShutdownThread() Unknown
  ntdll.dll!RtlExitUserThread()  Unknown
  KernelBase.dll!FreeLibraryAndExitThread() Unknown
  ucrtbase.dll!common_end_thread()  Unknown
  ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>()  Unknown
  kernel32.dll!BaseThreadInitThunk() Unknown
  ntdll.dll!RtlUserThreadStart() Unknown

(The impl for _endthreadex just immediately jmps to common_end_thread). Note that its hanging in FreeLibraryAndExitThread, which is what the DLLInit issue in [1] is about -- but you aren't in DLLInit in any way I can see. I get this hang every time I go to [2], start a webrtc session, stop it, and then shut down (with a new profile).

I don't know what DLL it is trying to unload but it probably doesn't matter -- there are apparently some undocumented locks used in the implementation of these functions that wreak all kinds of havok on people's code. I don't see where you are doing anything with LoadLibrary that should be related so its probably a superfluous (to your case) lock. Things that come from nowhere are hard to reason about.

FYI, the unload may need something from the main thread, which is stuck doing this:

  ntdll.dll!NtWaitForSingleObject()  Unknown
  KernelBase.dll!WaitForSingleObjectEx() Unknown
  xul.dll!std::sys::windows::thread::Thread::join() Line 62 Unknown
> xul.dll!std::thread::JoinInner<()>::join<()>() Line 1326  Unknown
  xul.dll!std::thread::JoinHandle<()>::join<()>(std::thread::JoinHandle<()> self) Line 1457 Unknown
  xul.dll!audioipc::core::{{impl}}::drop(audioipc::core::CoreThread * self) Line 34 Unknown
  xul.dll!core::ptr::real_drop_in_place<audioipc::core::CoreThread>(audioipc::core::CoreThread *=0x000001fd68dbed90) Line 175 Unknown
  xul.dll!core::ptr::real_drop_in_place<audioipc_server::ServerWrapper>(audioipc_server::ServerWrapper *=0x000001fd68dbed90) Line 175 Unknown
  xul.dll!core::ptr::real_drop_in_place<alloc::boxed::Box<audioipc_server::ServerWrapper>>(audioipc_server::ServerWrapper * *=0x000000752adff0f8) Line 175  Unknown
  xul.dll!core::mem::drop<alloc::boxed::Box<audioipc_server::ServerWrapper>>(audioipc_server::ServerWrapper * _x=0x000001fd68dbed90) Line 704 Unknown
  [Inline Frame] xul.dll!mozilla::`anonymous namespace'::ShutdownAudioIPCServer() Line 164  C++
  xul.dll!mozilla::CubebUtils::ShutdownLibrary() Line 635 C++
  xul.dll!nsLayoutStatics::Shutdown() Line 384  C++
  [Inline Frame] xul.dll!nsLayoutStatics::Release() Line 44 C++
  [Inline Frame] xul.dll!Shutdown() Line 127  C++
  xul.dll!nsLayoutModuleDtor() Line 262 C++
  xul.dll!nsComponentManagerImpl::Shutdown() Line 935 C++
  xul.dll!mozilla::ShutdownXPCOM(nsIServiceManager * aServMgr) Line 727 C++
  xul.dll!ScopedXPCOMStartup::~ScopedXPCOMStartup() Line 1231 C++
  [Inline Frame] xul.dll!mozilla::DefaultDelete<ScopedXPCOMStartup>::operator()(ScopedXPCOMStartup * aPtr=0x000001fd68d770f0) Line 487  C++
  [Inline Frame] xul.dll!mozilla::UniquePtr<ScopedXPCOMStartup,mozilla::DefaultDelete<ScopedXPCOMStartup>>::reset(ScopedXPCOMStartup * aPtr) Line 324 C++
  [Inline Frame] xul.dll!mozilla::UniquePtr<ScopedXPCOMStartup,mozilla::DefaultDelete<ScopedXPCOMStartup>>::operator=(void *) Line 297  C++
  xul.dll!XREMain::XRE_main(int argc, char * * argv, const mozilla::BootstrapConfig & aConfig={...}) Line 4718  C++
  xul.dll!XRE_main(int argc, char * * argv, const mozilla::BootstrapConfig & aConfig) Line 4752 C++
  [Inline Frame] firefox.exe!do_main(int argc, char * * argv=0x000001fd68d0a060, char * * envp=0x000001fd66e77b60) Line 217 C++
  firefox.exe!NS_internal_main(int argc=0x00000003, char * * argv, char * * envp=0x000001fd66e77b60) Line 331 C++
  firefox.exe!wmain(int argc, wchar_t * * argv=0x000001fd66e66490) Line 131 C++
  [Inline Frame] firefox.exe!invoke_main() Line 90  C++
  firefox.exe!__scrt_common_main_seh() Line 288 C++
  kernel32.dll!BaseThreadInitThunk() Unknown
  ntdll.dll!RtlUserThreadStart() Unknown

I avoid this by replacing [3] with a wait on a new Event that is signaled in thread_proc when you get the shutdown event (same idea as the shutdown Event but in the other direction). That should work and avoid whatever these undocumented locks are up to. This will also fix Bug 1614585, although I intend to land the fix I mention in Bug 1614585 comment 2, because I believe the issue still exists with plugin and main processes, even though we don't see crash stacks for them (yet).

---

[1] https://stackoverflow.com/a/10557979/88804
[2] https://janus.conf.meetecho.com/echotest.html
[3] https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/media/libcubeb/src/cubeb_wasapi.cpp#350

Comment 31

[David Parks [:handyman]]

Attachment: Bug 1430907: Part 2 - Use Windows Event to signal death of monitor_device_notification thread r=kinetik

We are running into some dangeous internal locking behavior in _endthreadex when shutting down the monitor_device_notifications thread in Windows Audio IPC. To avoid deadlock, this patch uses its own Windows Event to synchronize the death of that thread with the Audio IPC Server thread that governs its shutdown.

Depends on D64445

Comment 32

[David Parks [:handyman]]

I'm having trouble getting clang-format to respect the fact that media/libcubeb is in the .clang-format-ignore file and shouldn't be auto formatted. So Part 2 is still a WIP.
sigh.

Comment 33

[Matthew Gregan [:kinetik]]

(In reply to David Parks (dparks) [:handyman] from comment #30)

In trying out a bunch of audio stuff, I regularly hit a cubeb IPC hang at shutdown. I wouldn't be surprised if this is the cause of Bug 1610640.

Bug 1610640 seems to have exited AudioIPC before the hang occurs (at least, it has bailed further than any logging I had in place). To verify, I did a quick try run with AudioIPC re-enabled in b-c and with your patch applied (just D64451) - unfortunately bc6 still hangs on shutdown. I'll try again with D64445 included, just in case (edit: no difference, still hangs).

Comment 34

[David Parks [:handyman]]

(In reply to Matthew Gregan [:kinetik] from comment #33)

(In reply to David Parks (dparks) [:handyman] from comment #30)

In trying out a bunch of audio stuff, I regularly hit a cubeb IPC hang at shutdown. I wouldn't be surprised if this is the cause of Bug 1610640.

Bug 1610640 seems to have exited AudioIPC before the hang occurs (at least, it has bailed further than any logging I had in place). To verify, I did a quick try run with AudioIPC re-enabled in b-c and with your patch applied (just D64451) - unfortunately bc6 still hangs on shutdown. I'll try again with D64445 included, just in case (edit: no difference, still hangs).

Yeah, I wouldn't be surprised if this is not the cause of bug 1610640 either. Would have been nice though. D64445 dramatically changes the performance profile of the Windows behavior in audio shutdown, which is what I assume led to the hang I saw (I've got no other sane explanation for why removing AudioSession from content would cause a hang in the main process). If adding it makes a difference to bug 1610640, its probably more of a coincidence than anything.

Comment 35

[David Parks [:handyman]]

Upstream. Derp.

I added a github pull request for the stuff in Part 2. Every external project does this differently but part 1 will cause the shutdown deadlock if it lands without part 2. Let me know if you need me to change something.

Comment 36

[Matthew Gregan [:kinetik]]

(In reply to David Parks (dparks) [:handyman] from comment #35)

Upstream. Derp.

I added a github pull request for the stuff in Part 2. Every external project does this differently but part 1 will cause the shutdown deadlock if it lands without part 2. Let me know if you need me to change something.

I reviewed and landed your PR upstream last week (thanks!) - just checking in about landing these patches - anything I can help with?

Comment 38

[David Parks [:handyman]]

What's the time frame for integrating the upstream changes? It looks like the last time was Jan 22. I'll need that to land that before part 1 or it will cause shutdown hangs.

Comment 39

[Matthew Gregan [:kinetik]]

I'll land the upstream update in bug 1621428.

Comment 40

[mgasser]

The issue is also on Linux (distro: Pop!_OS) on website with infinite scrolling and video on it (like 9gag or else).

It create infinite process for sound until the system can't create more (and no sound anymore on the whole system) and when it happen, Firefox will freeze when opening a NewTab (but tab already opened still work, it will only freeze when opening a new one when the system reach the max Firefox sound process that can be created).

Comment 41

[Matthew Gregan [:kinetik]]

(In reply to David Parks (dparks) [:handyman] from comment #38)

What's the time frame for integrating the upstream changes? It looks like the last time was Jan 22. I'll need that to land that before part 1 or it will cause shutdown hangs.

Part 1 is safe to land now. Part 2 is obsoleted by bug 1621428's landing.

Comment 42

[Matthew Gregan [:kinetik]]

(In reply to mgasser from comment #40)

The issue is also on Linux (distro: Pop!_OS) on website with infinite scrolling and video on it (like 9gag or else).

This bug is about a Windows specific issue. Can you please file a new bug (and CC me) for the issue you're seeing?

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/483dac65ecb0
Part 1 - Remove AudioSession from Windows content process r=kinetik

Comment 44

[David Parks [:handyman]]

Landed. Thanks :kinetik!

Comment 45

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/483dac65ecb0