Open Bug 1515549 Opened 11 months ago Updated 5 months ago

Every change to audio stream resets application volume to 50%

Categories

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

64 Branch
defect

Tracking

()

REOPENED

People

(Reporter: apx.riax, Assigned: achronop)

References

Details

Attachments

(1 file)

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.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
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.
Status: UNCONFIRMED → NEW
Rank: 15
Ever confirmed: true
Priority: -- → P2
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
See Also: → 1422637
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.
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).
See Also: → 1474189
Duplicate of this bug: 1518245
Pushed by achronopoulos@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/849f81f21979
Avoid resetting volume in every AudioSink restart in case volume has changed outside firefox. r=jya
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Depends on: 1519349
Depends on: 1519350
Assignee: nobody → achronop

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

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

Status: RESOLVED → REOPENED
Flags: needinfo?(achronop)
Resolution: FIXED → ---
Target Milestone: mozilla66 → ---
Depends on: 1519690
Depends on: 1519422

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

Flags: needinfo?(achronop)
Duplicate of this bug: 1524849
See Also: → 1537946
You need to log in before you can comment on or make changes to this bug.