Open Bug 1407288 Opened 2 years ago Updated 4 months ago

Firefox's level in Volume mixer resets to system default level after restart [Win7]

Categories

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

56 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: wilco13_muppet, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0

Steps to reproduce:

1. Start firefox
2. Set volume in volume mixer to a lower value (e.g. 25%)
3. Close firefox
4. Start firefox
5. Check volume in volume mixer it will be at 100% or max default.

Actual results:

after restarting firefox, volume level reset to 100%

Expected results:

Volume level should be at % that was set before restart (e.g. 25%)
Component: Untriaged → Audio/Video: cubeb
Product: Firefox → Core
Has Regression Range: --- → yes
Was fine in 0.55 started happening since the update to 0.56
Anthony can you please check if this is properly prioritized?
Rank: 25
Flags: needinfo?(ajones)
Keywords: regression
Priority: -- → P2
This is likely fall out from multi-e10s and can supposedly be fixed in widget/windows/AudioSession.cpp

Jim - do you want to look into this?
Flags: needinfo?(ajones) → needinfo?(jmathies)
I see Firefox and Mozilla Firefox appear on the mixer.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #4)
> I see Firefox and Mozilla Firefox appear on the mixer.

I'm guessing this happens when you have an old install that has been upgraded to 56. Maybe uninstalling then reinstalling Firefox will magically fix the issue.
Assuming this issue is a problem with audio sessions.  With current Nightly I see multiple volume controls for "Nightly" when playing media in several tabs.

The session IDs match, but we have different grouping parameters which may be the issue.  It also looks like the audio sessions are single-process, maybe they need to be cross-process (the MSDN page on audio sessions mentions this, but I haven't spotted how to do so yet).

    Active session #1
        Icon path:
        Display name:
        Grouping parameter: {020d0b77-568b-475b-a82b-ea9985506bc0}
        Process ID: 13404 (single-process)
        Session identifier: {0.0.0.00000000}.{8ac6164b-309e-41e9-aa2e-be13881eadbc}|\Device\HarddiskVolume6\Program Files\Nightly\firefox.exe%b{00000000-0000-0000-0000-000000000000}
        Session instance identifier: {0.0.0.00000000}.{8ac6164b-309e-41e9-aa2e-be13881eadbc}|\Device\HarddiskVolume6\Program Files\Nightly\firefox.exe%b{00000000-0000-0000-0000-000000000000}|1%b13404
        System sounds session: no

    Active session #2
        Icon path:
        Display name:
        Grouping parameter: {af0245c3-8cef-40c6-8ec4-35db28930fb4}
        Process ID: 2376 (single-process)
        Session identifier: {0.0.0.00000000}.{8ac6164b-309e-41e9-aa2e-be13881eadbc}|\Device\HarddiskVolume6\Program Files\Nightly\firefox.exe%b{00000000-0000-0000-0000-000000000000}
        Session instance identifier: {0.0.0.00000000}.{8ac6164b-309e-41e9-aa2e-be13881eadbc}|\Device\HarddiskVolume6\Program Files\Nightly\firefox.exe%b{00000000-0000-0000-0000-000000000000}|1%b2376
Audio code is a bit of a mess in Firefox as we have a few audio libraries that aren't latched into our session registration here - 

http://searchfox.org/mozilla-central/source/dom/plugins/base/npapi.h#514

We need to have 3rd party libraries query their host for the session id. We also need to convert the global audio registration that happens in startup to a on demand type registration.

I'd welcome any change that improves things.
Flags: needinfo?(jmathies)
So i reverted to the previous version 0.55.3 and my problem is gone.
I see one diff in the windows/AudioSession.cpp
https://hg.mozilla.org/mozilla-central/diff/312f7a5a2c08/widget/windows/AudioSession.cpp
But at a glance i have a feeling that isn't the culprit, has anything changed in the code that uses the AudioSessions?
Yep. 55.0.3 is fine. Issue starts with 56.
Just tested 57.0 still an issue.
so im back to 55.0.3 again
The bug still exists, 59.0.2 Win10 64-Bit

(in combinaion with Bug 1358372, which is seemingly fixed in Firefox 60)
Flags: needinfo?(drno)
Based on the descriptions I guess this problem got created through e10s (multi-process), or?

Kinetik: would this automatically get fixed through the cubeb remoting work (since then only the parent interacts with the system level audio system)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(drno) → needinfo?(kinetik)
(In reply to Nils Ohlmeier [:drno] from comment #12)
> Based on the descriptions I guess this problem got created through e10s
> (multi-process), or?

The multiple volume controls issue is.  It's likely that this issue with preserving state/volume is related, but I'm not totally sure.  I'd guess we end up with a different persistent session (according to Windows) somehow and therefore it doesn't use the stored volume state from a previous (unrelated, to the OS) session.

> Kinetik: would this automatically get fixed through the cubeb remoting work
> (since then only the parent interacts with the system level audio system)?

I think so.  It'll help, since at least the session management returns to the simpler state of pre-e10s.
Flags: needinfo?(kinetik)
See Also: → 1454185
This also happens on Windows 10 and is a source of a major headache, 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 it to system level "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 is to every time open the Volume Mixer and lower the Firefox bar. 

It doesn't help that there is another bug where Firefox injects dozens of Firefox entries under Volume Mixer. If any Mozilla developers are using Windows 10, could you possibly verify the level of impact this and the multiple Volume Mixer entry bug have, and perhaps escalate the priority?

I'm experiencing this problem on Firefox 65.0. I upgraded to version 65 from 64, which had the problem too. Version 64 was a fresh installation (on Linux Mint 19.1).

You need to log in before you can comment on or make changes to this bug.