1515549 - Every change to audio stream resets application volume to 50%

Status: RESOLVED DUPLICATE of bug 1422637

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

Description

[Ben Landin]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

1) Open and play any YouTube video
2) Pause the video
3) Resume the video
4) Seek forward anywhere in the video
5) Skip to the next video or open a different video


Actual results:

At every step, Firefox's volume in the volume mixer (currently mislabeled as "AudioIPC Server"; see #1435614) is being reset to 50%, which on my system is extremely quiet with the master volume at anything less than max.


Expected results:

Firefox should not be resetting the volume when the audio stream changes.

Comment 1

[Dan Minor [:dminor]]

Thanks for your report.

I can confirm that Firefox 66 is resetting the volume in the volume mixer. In my case, it was already at or near 100%, but if I manually switched it to 50%, when I paused/resumed/seeked it would reset it back to 100%. This happened consistently when seeking, but only occasionally when pausing and resuming.

Comment 2

[Alex Chronopoulos [:achronop]]

This is because every time we do a Pause/Play or Seek we call `AudioSinkWrapper::Start` using the stored parameters [1] which contains the last values set in MediaElement. This method eventually set the volume every time to the value in the parameters [2]. When you change the volume from outside of firefox (pavucontrol) the new level will be reset on next  `AudioSinkWrapper::Start`. I expect to have the same issue the other way around, from high volume to a low one etc depending on the volume level on the MediaElement.

A solution would be not to set the volume on Pause/Play or Seek. If this is difficult to identify in `AudioSink` class we can work around it by storing the current volume value in parameters on `AudioSinkWrapper::Stop()`.

[1] https://searchfox.org/mozilla-central/source/dom/media/mediasink/AudioSinkWrapper.cpp#170
[2] https://searchfox.org/mozilla-central/source/dom/media/mediasink/AudioSink.cpp#190

Comment 3

[Alex Chronopoulos [:achronop]]

Hmmm cubeb does not have an API to get the current volume. The other option is to avoid setting the volume at all if we don't have a new value from media element. That will work for Pause/Play and Seek but will reset the volume when we mute/unmute and when we create a new media element, for example if we change video in YouTube.

Comment 4

[Alex Chronopoulos [:achronop]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d6286d03dce9a0d027fb4df7ee13a7d66f94b3a3

Comment 5

[Alex Chronopoulos [:achronop]]

Attachment: Bug 1515549 - Avoid resetting volume in every AudioSink restart in case volume has changed outside firefox. r?pehrsons

Avoid resetting volume in every AudioSink restart to stop unexpected volume change during play/pause and seek. Volume changes could occur if the volume has been modified outside firefox (for example pavucontrol in Linux).

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/849f81f21979
Avoid resetting volume in every AudioSink restart in case volume has changed outside firefox. r=jya

Comment 8

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/849f81f21979

Comment 9

[Noemi Erli[:noemi_erli]]

Backed out changeset 849f81f21979 (Bug 1515549) per achronop's request a=backout

Backout: https://hg.mozilla.org/mozilla-central/rev/485de31371e04407432d932a039cbeb40fa88727

Comment 10

[Alex Chronopoulos [:achronop]]

Thanks, I'll come up with something better. I am clearing the NI for now.

Comment 12

[kurmikon]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1422637#c5

Comment 13

[Dávid Horváth]

Unexpected significant increase in volume may cause hearing damage. So I suggest to increase the ticket bug too.

Comment 14

[Dávid Horváth]

ticket bug bug severity

Comment 15

[Dávid Horváth]

Sometimes it changes to 100%. An unintentional increase from 20% to 100% can be a big surprise.

Comment 16

[Dávid Horváth]

Currently, (on my debian9 machine) application volume and device volume are also restoring to 100%. So every pause/continue causes a 20x increase. No other app or browser has this problem (at least what i use).

Comment 17

[Paul Davis]

I ran into this issue (in some form) a couple of days ago after upgrading my system from Debian Buster to Bullseye. I use Firefox directly from Mozilla (88.0.1) and started noticing strange behavior with volume in Firefox where I had not before.

I was not willing to restore my system from a backup just to check this, so I booted my laptop, which uses the Firefox ESR (78.10.0) and compared the behavior.

It did not take long to discover what I think is the critical difference. The ESR release does not connect volume controls in various HTML5 players to the corresponding PulseAudio stream volume. Examples:

• youtube volume control
• twitter video volume control

In 78.10.0esr, adjusting either of these controls has no effect whatsoever on the PulseAudio volume control level.

In 88.0.1, adjusting either of these controls directly alters the PulseAudio volume control level for the corresponding audiostream.

This also explains the behavior in the bandcamp player widget, in which seeking/locating within a track causes a PulseAudio volume control level reset when using 88.0.1, but no change at all in 78.10.0esr (*)

I don't know who thought that it was a good idea to tie the in-browser/in-widget volume controls to the stream volume controls. In my opinion (**) this is a terrible mistake. The stream volume controls are there for the user to adjust using e.g. pavucontrol. If the browser needs to adjust the volume, it should alter its own output. Even though these streams are per-application (or, in this case, even per-tab), I think it is fundamentally wrong to assume that the controls associated with the streams (e.g. volume) are for the application to adjust. They are for the user to adjust outside of the browser (and they were before).

I also confirmed that Chrome does not do this. Its behavior is like Firefox 78.10.0esr - changing the volume level in e.g. youtube has no effect at all on the PulseAudio stream volume level.

(*) one thing I have not figured out yet is why I never saw this behavior when using 88.0.1 with my previous Debian setup. This remains a mystery.

(*) although I'm just another Firefox user, I'm not exactly a random user when it comes to audio on Linux. I'm the lead developer of Ardour, and the original author of JACK (the JACK Audio Connection Kit), as well as a contributor (long time back) to both the design and implemention of ALSA. That doesn't mean that my opinion is automatically correct (far from it!), but I am someone who does understand audio on Linux at a very, very deep level. Assuming that I've understood what is going on here, I really think someone got this design extremely wrong.

Comment 18

[Paul Davis]

OK, continuing exploration ... my previous comment seems incorrect. I fired up 78.10.0esr on my Debian Bullseye system, and the youtube volume control does in fact control the PulseAudio stream volume, just like 88.0.1. It therefore appears that the change I've observed is between Debian versions (and thus likely PulseAudio versions). I still think the design is really wrong, but will need to dig deeper into the reasons why I don't see this on my laptop (Debian "old") with 78.10.0esr.

Comment 19

[Dávid Horváth]

Another variant of the problem. While I was watching a youtube video, the mail notification sound (a really unexpected random event from an other firefox tab) exploded at a huge volume, and also temporarily amplified the video sound. Random events poke my volume settings.

Comment 20

[kurmikon]

Not only this design is really wrong, but they don't have any clue on how to resolve the issue.

Someone tried in the past with a commit, but broke all the audio stack and the change was reverted.

Comment 21

[C.M.Chang[:chunmin]]

I believe this issue is the same as bug 1422637. I am going to close this. Please move the discussion to bug 1422637.