Open Bug 1422637 Opened 8 years ago Updated 2 months ago

Volume does not stay where it is manually set using pulseaudio

Categories

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

Product:
Core
Component:
Audio/Video: cubeb
Version:
57 Branch
Platform:
All
Linux
Type:
defect

Tracking

()

People

(Reporter: crazylegoguy, Assigned: padenot)

References

Details

Attachments

(2 files)

GitHub Pull Request
45 bytes, text/x-github-pull-request
Details | Review
Showing the issue happens with pipewire
6.33 MB, video/x-matroska
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171121103731 Steps to reproduce: Manually set the volume of any firefox tab using pulseaudio mixer then open a new tab or advance the playback of a youtube video using the arrow keys. Actual results: When playing youtube videos, the volume changes from 75% (where I manually set it) to 90% (it used to be 100%, but I have no idea what I did to change this behavior) when any change occurs. This is the same for opening new tabs as well. Expected results: Firefox should remain at 75% where it was originally set instead of changing volume.
Component: Untriaged → Audio/Video
Product: Firefox → Core
(In reply to crazylegoguy from comment #0) > Manually set the volume of any firefox tab using pulseaudio mixer then open > a new tab or advance the playback of a youtube video using the arrow keys. Are you setting a stream volume, application volume or master volume?
Flags: needinfo?(crazylegoguy)
I’m setting the volume for the application.
Flags: needinfo?(crazylegoguy)
Component: Audio/Video → Audio/Video: Playback
Component: Audio/Video: Playback → Audio/Video: cubeb
That's real, I use pavucontrol to set the volume (something lower than 100%) on 2 different tabs. When I seek a new point on first video, the volume of the second video does to 100%. The same the other way around.
Status: UNCONFIRMED → NEW
Rank: 25
Ever confirmed: true
Priority: -- → P3
Depends on: 1049480
No longer depends on: 1049480
It appears to me, the solution to this would be a volume sliders for each tab. Those could be in sync with pavucontrols values. The resulting volume would be (JS-volume * Tab-volume). Is that a feasible way to solve it, UX wise? I also opened a bug in https://github.com/kinetiknz/cubeb/issues/478 since it seems to not yet support the volume settings back channel from pulseaudio to cubeb. For me I hacked a workaround https://pastebin.com/WVjnS00T which creates a null device to be the sink for Firefox. Basically it ignores Firefox's volume settings (or rather expects it to be at 100%) and lets me set it in pavucontrol only.
See Also: → 1515549

I can confirm this bug on my Arch Linux distro. As stated here (https://bbs.archlinux.org/viewtopic.php?id=244401) Firefox synchronizes HTML5 player volume level on its Pulseaudio sink (AudioIPC Server), therefore changes of volume level inside the player are reflected on AudioIPC Server and these are visible in the mixer (Kmix or pavucontrol). But if the user changes volume from the mixer affecting AudioIPC Server sink, the modifications are not reflected inside the HTML 5 player.

I think this is a design issue. If you want to synchronize player volume with pulseaudio sink related to Firefox, you should do it both way, not only one. Besides, this causes other issues when PulseEffect is running. At this point I prefer Chromium behavior: volume is not synchronized, I can set volume level inside the mixer manually and it is stored across sessions.

I tried this on Windows and the synchronization is missing, so it seems a bug only related to Pulseaudio on Linux.

And, please, change name, AudioIPC Server is not friendly. If I see "Chromium playback" for Chromium, I'd like to see "Firefox playback" for Firefox.

I confirm that volume of one of "AudioIPC Server" available in my PulseAudio list, sometimes turns to 75% or 79% when I listen to Youtube videos.
firefox-67.0-4.fc30.x86_64
Fedora 30 KDE with Pulseaudio flat volumes off

I confirm that sort of behaviour on firefox 74.0 and Pulseaudio 13.
Sometimes volume on new playback tab is set to something between 75% and 90% even tho I've always set "Firefox Audio Stream" volume to 100%
Volume is not synchronized with HTML5 player as it is also set on 100% volume

On top of that why every single tab shows up as new "device" in the volume mixer? That's ridiculous, no other app exhibits that behaviour and no other sane app changes its own mixer volume

It's not just that it ignores volume set externally, it's that it defaults to full 100% volume each time you open a new page with a multimedia object in it, (and possibly enable sound if "Block websites from automatically playing sound" isn't set)

At least with mine, if I open a facebook or youtube video, the player is initially in mute state, and I have to unmute it by clicking on the volume icon (annoying by itself, since if I just went to a media player, why wouldn't I want the sound to play? But the alternative is scrolling down a page and some idiot sets up an autoplay ad and I get blasted with their inane drivel). Once unmuted, I have the full 85dB of sound playing through my speakers 2 feet behind my head. I then slam the pause button and move the system volume control down, then focus back on the player, press play, and firefox helpfully sets it back up to 100%!

Why can't Firefox just be like every other damn browser out there, and not fiddle with the volume without my consent? I am confused as to why so many more people don't consider this a showstopped. I just finally got sick of how awful Chrome has become recently, but this is unusable nonsense. I don't want to have to go back to the bad old days of maintaining two browsers just so one can competently play audio.

Meanwhile, in reply to Fahrradkette from comment #4:

For me I hacked a workaround https://pastebin.com/WVjnS00T which creates a
null device to be the sink for Firefox. Basically it ignores Firefox's
volume settings (or rather expects it to be at 100%) and lets me set it in
pavucontrol only.

Does this still work? From reading the code, I don't understand how this hooks into pulseaudio and/or firefox, and it doesn't seem to do anything other than fire up pavucontrol with no apparent modifications to the streams.

I think the root cause is that our audio backend does not expose an API to retrieve the current volume level so we default it to 100% every time a new media element is created. We should change that. In the meantime can you please experiment with media.default_volume in about:config. It must change that default level to whatever you like. Please let us know how it works, I haven't tried it myself.

No it's because we open an audio stream per process, we have multiple processes and we use server side volume handling that doesn't work the way people expect it to, that interacts badly with websites setting volumes to 1.0.

I'm tired of hearing about this, I'll remove this altogether.

I always thought this behaviour is meaningless. See here.

Removing this is the best thing you can do, behaving like every other browser on the planet.

See Also: → 1627325
Attached file GitHub Pull Request —

The fix is here

Assignee: nobody → padenot
Depends on: 1631448
Priority: P3 → P1

crazylegoguy,

the fix is landed in bug 1631448. Would you mind checking if this is fixed in Firefox Nightly?

Flags: needinfo?(crazylegoguy)

Same for other reporters that can repro, can you check in latest Nightly ? The tarball can be decompressed, ran directly and deleted.

By default, this happens on non-debian-based system I think, although you can configure a debian-based system to repro.

Flags: needinfo?(tom.wrobel90)
Flags: needinfo?(tim.w.connors)
Flags: needinfo?(lvogel)
Flags: needinfo?(kurmikon)

We had to back this out, because apparently pulse now set all Nightly processes to 0% volume we we remove the calls to the volume pulse API, which didn't really expect. We'll investigate and reland next cycle.

Flags: needinfo?(tom.wrobel90)
Flags: needinfo?(tim.w.connors)
Flags: needinfo?(lvogel)
Flags: needinfo?(kurmikon)
Flags: needinfo?(crazylegoguy)
See Also: → 1632093

Which is your plan? Only disabling synchronization of volume on pulse sink or also making Firefox using a single pulse sink instead of one per each tab?

I'd like both.

Still happening in latest releases...

Having to manually readjust the volume in every YouTube video (and some other sites) by doing just about anything (rewinding, pausing/playing, setting volume via arrow keys) is starting to become really annoying.

I stumbled upon this bug after constant annoyance while skipping through songs in YouTube Music. In reference to the Python script posted earlier, I figured I'd post a raw command line version which will achieve I believe more or less the same thing for folks should they want to isolate Firefox to a virtual sink which can then be controlled independently from a new loopback source:

$ pactl list short sinks
4       alsa_output.pci-0000_00_1b.0.analog-stereo      module-alsa-card.c      s16le 2ch 44100Hz       RUNNING
$ pacmd load-module module-null-sink sink_name=virtual
$ pacmd load-module module-loopback source=virtual.monitor sink=alsa_output.pci-0000_00_1b.0.analog-stereo
$ pactl list short sinks
4       alsa_output.pci-0000_00_1b.0.analog-stereo      module-alsa-card.c      s16le 2ch 44100Hz       RUNNING
5       virtual module-null-sink.c      s16le 2ch 44100Hz       RUNNING

At this point, I have a separate "Null Output" sink available in pavucontrol which I can use for Firefox instead of my normal "Built-in Audio Analog Stereo" sink. And if I select "All Streams" on the Playback tab, I then also see my loopback source now which I can keep at my desired volume without worry of it being reset by Firefox.

Hope that helps others.

Thank You @nipsy ! This worked great for me :)

To state the obvious, make sure you use your device name for the sink in the 3rd command... yes I made this mistake :)

(In reply to richard.logwood from comment #20)

Thank You @nipsy ! This worked great for me :)

To state the obvious, make sure you use your device name for the sink in the 3rd command... yes I made this mistake :)

Update: I'm having very mixed success with this and will default to using Chrome for audio feeds (which works ok) until this bug gets resolved.

In my case, the default PA volume depends on the media. For example, Angel -- Massive Attack loads at 91% (-2.45dB). Setting the tab volume in pavucontrol to 100%, then hitting the left arrow while playing removes the AudioStream row from pavucontrol before its volume is reset to 91%.

Screengrab showing reset.

Tested on FF Nightly 81.0a1 (2020-08-11) (64-bit).

The null output loopback workaround is working for me, or it at least lets me adjust the overall volume of Firefox when needed. The sink-input still gets reset to whatever random volume Firefox feels like all the time though.

I confirm the bug and that this is excruciating - however I much prefer Firefox over any other browser, and I'd like to give all the devs and the project a big hug. Looking forward to the fix making it to stable-branch.

Another way to trigger the problem is:

  1. open a youtube video
  2. low the volume from pulse audio, to let's say, 50%
  3. change the quality of the youtube video in youtube video settings
  4. you will get the audio level in pulse audio back to 100%

I confirm the bug on my PulseAudio Arch Linux system.

@Germano Massullo
This is right. I can relate.

I can only confirm this annoying behaviour on KDE Neon 5.20.4 (based on Ubuntu Focal Fossa 20.04).
When listening to music playlists on YouTube, the volume is inadvertently reduced to an arbitrary value (depending on the media) each time a new clip starts playing.
The virtual sink is useless for me because it would only allow to further reduce the volume, but I just want it to stay at 100%.
Please fix this in stable and esr as soon as possible, this bug has been around for way too long.

Repro with Firefox 84.0 on Arch Linux. A mitigation that works for me is to tweak the media.volume_scale option in about:config.

(In reply to Sinkerine from comment #28)

Repro with Firefox 84.0 on Arch Linux. A mitigation that works for me is to tweak the media.volume_scale option in about:config.

Again, changing the volume scale in about:config only helps if you want to decrease the volume, but if you need it stay at full level that's useless...

(In reply to acebone from comment #24)

I confirm the bug and that this is excruciating - however I much prefer Firefox over any other browser, and I'd like to give all the devs and the project a big hug. Looking forward to the fix making it to stable-branch.

I can only agree. I like Firefox for its customisability and am very used to it, but this bug is troubling me.

(In reply to Manuel Geißer from comment #27)

I can only confirm this annoying behaviour on KDE Neon 5.20.4 (based on Ubuntu Focal Fossa 20.04).
When listening to music playlists on YouTube, the volume is inadvertently reduced to an arbitrary value (depending on the media) each time a new clip starts playing.
The virtual sink is useless for me because it would only allow to further reduce the volume, but I just want it to stay at 100%.
Please fix this in stable and esr as soon as possible, this bug has been around for way too long.

They won't fix it because they are busy on something else, don't have time, neither any clue on how to work on it. Someone already tried in the past and failed breaking all the audio stack.

Recently this became not a big issue to me because I switched to a Chromium-based browser and when I was using Firefox I set PulseEffects with this preset which is leveling the volume to the max whichever thing Firefox does and it works also as loudness equalizer for other applications.

It works only for PulseAudio, not Pipewire, at least until PulseEffects will have official Pipewire support.

(In reply to kurmikon from comment #31)

They won't fix it because they are busy on something else, don't have time, neither any clue on how to work on it. Someone already tried in the past and failed breaking all the audio stack.

Yeah, I know... The problem is just: this issue affects many, many users, as the vast majority of distributions ship with Pulse as audio system and Firefox as default browser.

I don't understand why PulseAudio at all permits applications to change their own volume in the system mixer. The mixer should be for the user to set volumes of different applications into proportions, and apps should never be able to change what the user has defined, I think. What was the original idea behind this? Why was this implemented?

Recently this became not a big issue to me because I switched to a Chromium-based browser and when I was using Firefox I set PulseEffects with this preset which is leveling the volume to the max whichever thing Firefox does and it works also as loudness equalizer for other applications.
It works only for PulseAudio, not Pipewire, at least until PulseEffects will have official Pipewire support.

Somehow making PulseAudio force Firefox to stay at 100% is what I am looking for, but this equalizer yet doesn't seem to fit because it affects all other applications as well.

(In reply to Manuel Geißer from comment #32)

Yeah, I know... The problem is just: this issue affects many, many users, as the vast majority of distributions ship with Pulse as audio system and Firefox as default browser.

I don't understand why PulseAudio at all permits applications to change their own volume in the system mixer. The mixer should be for the user to set volumes of different applications into proportions, and apps should never be able to change what the user has defined, I think. What was the original idea behind this? Why was this implemented?

I don't have idea, but it's not a PulseAudio issue since it's not happening in other browsers, neither in other applications. The future multimedia pipeline on Linux will be Pipewire (Arch Linux already adopted it), I wonder if this would happen in the case Firefox supports it directly.

Somehow making PulseAudio force Firefox to stay at 100% is what I am looking for, but this equalizer yet doesn't seem to fit because it affects all other applications as well.

You can disable the "Process All Output" option and enable only Firefox.

I think I have finally found a good workaround for me: The extension enhanced-h264ify (https://github.com/alextrv/enhanced-h264ify) has an option to disable the YouTube html5 loudness normalization.

(In reply to Manuel Geißer from comment #34)

I think I have finally found a good workaround for me: The extension enhanced-h264ify (https://github.com/alextrv/enhanced-h264ify) has an option to disable the YouTube html5 loudness normalization.

Yes, I can confirm the extension enhanced-h264ify is working for me as well. It is helpful with hardware acceleration too. Thanks!

TR;DR

This is a Youtube-specific feature meant to normalize the volume of different videos to the same perceived (peak) loudness. But this, coupled to some weirdness in Firefox's PulseAudio backend, results in YouTube's JavaScript code changing the PulseAudio mixer (sink) value, instead of some other volume level that should stay hidden inside the process. So if the user herself tweaks the PulseAudio sink volume from the OS mixer, it invariably gets reset the next time the Youtube script performs a seek or a quality change or anything else.

For now the enhanced-h264ify extension is a good way to block this specific offending script on Youtube. But IMHO Firefox should decouple the HTML5 volume setting from the PulseAudio sink volume, as :padenot tried doing before.

By the way, I think Firefox should keep using a separate PA sink per process / tab, as it does now, because this makes it easier to control or redirect the audio coming from different websites, which is useful for a variety of reasons. Chrome seems to be doing the same as well, so IMHO this "multiple sink" aspect should not be changed.

(In reply to Tobia from comment #36)

TR;DR

This is a Youtube-specific feature meant to normalize the volume of different videos to the same perceived (peak) loudness. But this, coupled to some weirdness in Firefox's PulseAudio backend, results in YouTube's JavaScript code changing the PulseAudio mixer (sink) value, instead of some other volume level that should stay hidden inside the process. So if the user herself tweaks the PulseAudio sink volume from the OS mixer, it invariably gets reset the next time the Youtube script performs a seek or a quality change or anything else.

There may also be other websites using HTML5 volume control, so the issue does not only affect YouTube and hence enanced-h264ify is not a full fix. Also, it seems like YouTube's new login "wall" (see https://github.com/yourduskquibbles/webannoyances/issues/245), which is shown in some countries, breaks the mechanism to disable volume normalisation.

For now the enhanced-h264ify extension is a good way to block this specific offending script on Youtube. But IMHO Firefox should decouple the HTML5 volume setting from the PulseAudio sink volume, as :padenot tried doing before.

By the way, I think Firefox should keep using a separate PA sink per process / tab, as it does now, because this makes it easier to control or redirect the audio coming from different websites, which is useful for a variety of reasons. Chrome seems to be doing the same as well, so IMHO this "multiple sink" aspect should not be changed.

I disagree about that - I think my Chromium (beta branch) doesn't do that, and this behaviour is more annoying than helpful for most users. Consider one wants to quickly and safely turn off audio for the entire Firefox application, then it is tedious to go through all seperate sinks and mute each of them. I can understand that controlling the volume for different tabs seperately may be useful for some rare conditions, but that's not what is commonly needed/wanted. It may also spam your system mixer if you have many tabs open.
If this feature is desired, then I think it should rather be implemented client-side in Firefox, maybe with some about:volume page. Also I'd like to note that Firefox does not do this on Windows or macos, and there is no point at handling it different on one platform.
Overall, I have to say that Firefox on Linux is a very disappointing experience, it seems like no one really cares about it due to the rather small number of users compared to the two proprietary platforms.

By the way, I think Firefox should keep using a separate PA sink per process / tab, as it does now, because this makes it easier to control or redirect the audio coming from different websites, which is useful for a variety of reasons

Getting 20 "Firefox: Audio Sink" on mixer list doesn't make anything easier

PA sink per window or per anonymous session would make much more sense from user perspective if you want more detailed control, especially if sinks will be named in recognizable way and not just "Audio sink".

Yeah, these issues used to happen with me every time as the volume didn't stay where it was set manually, but then I ordered an amp for guitar from an online store using their positive grid coupons and I got an amplifier, and the volume issue solved in one go at an affordable rate.

I've reproduced the bug with Firefox version 88.0 on Lubuntu.

(In reply to Tobia from comment #36)

But this, coupled to some weirdness in Firefox's PulseAudio backend, results in YouTube's JavaScript code changing the PulseAudio mixer (sink) value, instead of some other volume level that should stay hidden inside the process.

This is precisely correct. It is a design error to have firefox adjusting the PulseAudio stream volume, ever. Firefox should adjust volume internally, like all other browsers and all other applications do.

It's there to prevent a burst of audio loud audio in the following scenario:

  • Play some audio at a particular volume
  • Pause the audio stream
  • Adjust the volume
  • Start the audio stream again

The only way to do this properly when the stream has a high latency is to use mixer-side volume. We've asked PulseAudio for a mixer-side input gain unaffected by the slider (that would be another gain stage), but afaik this is still not available.

We've tried to change this to use our own volume (which we already do if PulseAudio is configured to use flat-volumes, side-stepping the issue completely), but we backed it out because of a bug that we couldn't reproduce, and other things of more importance have taken precedence since then.

As always, this is in theory easy to fix, the code is there, it's only code removal, the patch has already been written.

If someone wants to fix this, and can reproduce and understands the bug resulting in no audio for quite a few people (in fact volume set to zero I think? but since ~nobody knows or care about per-app volume it's essentially equivalent), please tell us, and we can get this fixed.

I don't want to go over old ground, but this all started with Firefox's lamentable decision to use the PulseAudio API directly, in complete contradiction to PulseAudio's creator's intention. Firefox and Skype are the only applications which do this.

There's no reason to ever pause the audio stream, you should just feed it silence. There's a JACK backend for Firefox audio, and it does not (last time I checked) have this issue because the design is completely different.

(In reply to Paul Davis from comment #43)

There's no reason to ever pause the audio stream

Not burning the battery of a Bluetooth device and allowing audio-competing policy schemes to work are two immediate reasons.

Please stay civil and source your affirmations. We've been talking more than a few times with the PulseAudio developers and not a single time it was mentioned that we weren't supposed to use the PulseAudio API directly. Case in point, just search on the web for software that do any kind of audio IO, and you'll see that lots of them will use Pulse's API directly.

In addition, downstream distros are enabling ALSA and Jack, and this works fine, and we review and take patches, and we've added ways to not use PulseAudio if one really wants that. And finally, this work admirably for the immense majority of the population. If you're not happy, we can talk and make changes, as always.

It's not the responsibility of a PulseAudio client to address power management on remote devices. PulseAudio can take care of it that by itself (e.g. by pausing the bluetooth stream when the incoming PA stream from the application is silent for more than some period of time).

How does pausing the stream allow for competing schemes? One of the main points of PulseAudio is that multiple applications can all share access to audio interface hardware, and the PulseAudio server continues to run regardless of whether or not your stream is paused.

Lennart and I built a mechanism into PulseAudio and JACK to allow them to inter-operate; that mechanism is completely unrelated to whether or not PA streams are paused or not.

Sourcing my affirmations ... hmm, I was a friend of Lennart at the time he was working on PulseAudio. He had a very clear goal of not adding a new API for applications to use to do audio I/O. He made this clear to me personally, and at the Linux Plumbers Conference (2009 I believe), and in some discussions on the Linux Audio Developers mailing list (when we questioned him on precisely this point).

This is precisely why PulseAudio implements a pseudo-device so that applications using the ALSA API will just keep working, regardless of whether or not the PulseAudio device or some hardware device is being used by the application. Unfortunately, as Lennart moved on from PulseAudio, subsequent developers on the project were less insistent that the API should not be used by applications. In the period 2005-2015 (roughly), the PulseAudio documentation was fairly clear on this point, whereas today the same documentation does make it appear as if it really is intended to be an API for applications. Nevertheless, it still remains the case that, to the best of my knowledge, Firefox and Skype are the only applications to have taken the path of actually using the PulseAudio API.

Re: applications ... ok, doing your suggested search does point to some other applications that opted to use PulseAudio directly, so I stand corrected on this. I was suprised to find that Clementine, the audio player I use 100% of the time, does this. However, most of these applications offer multiple API choices. For Clementine, for example, I use it with JACK exclusively, and in fact it offers an almost crazy list of options.

If we could identify what in the system was setting volumes on new streams, then perhaps we could detect that and revert the fix for bug 1632093 in situations where that initial volume setting is not happening.

[Tracking Requested - why for this release]:

tracking-firefox89: --- → ?
status-firefox89: --- → fixed
status-firefox89: fixed → ---

(In reply to Paul from comment #42)

I arrived here because I had this problem, the volume was going to zero when I pressed right or left key in a youtube video. Using FF 91.0.2 on Mageia 8.

I just understood the problem and I may have been able to reproduce, at least one part of it: I think what happened is that I had muted the tab without noticing it, then when the video plays, the sound volume in pulse is zero. So I increased the volume to 100%. Now, each time I do a fast forward (right key), the sound drops back to zero. So I change it back in pulse (pavucontrol or KDE sound mixer in my case), but it will drop to zero every time I do any small action, pause, forward, rewind, etc.
Unmute the tab allowed FF to be at 100% sound volume again, and it stays there - of course the bug is still there: if I change FF volume to e.g. 50% and do a fast fwd, the sound will go again to 100%.

But the mute problem was the most annoying problem for me, it had happened randomly in the past and I did not figure out why until today, so I wanted to leave a trace here so that people check if the tab is muted or not.

See Also: → 1731443
Regressions: 1632093
See Also: 1632093 →

Compare our attempt with what chrone does , the only difference I noticed is that chrome adjusts the volume if its value is in [0, 1) while we adjust the volume if it's not 1. Not sure if it matters, or we guarantee the volume value is in [0, 1).

There are two separate issues here.

One is that the volume is reset at specific times when it should not be. For example, visit a bandcamp or similar page with a playlist. Start playing the first item in the list. Using PulseAudio Volume Control, change the volume for the page's audio stream. Now use a button on the page to skip to the next item. The volume is reset.

You can do the same on YT: start a video, use pavolctl to reduce the voume, then skip to a new location in the video. The volume is reset.

If you're going to adjust the volume in a system external to Firefox, you need to make the interaction duplex (i.e. notice changes made externally, not just those originating from HTML5 elements).

The second deeper issue is that as explained above, Firefox should not be adjusting PulseAudio (or ALSA or Pipewire) gain controls at all. These exist for users, not applications. Firefox should have its own internal gain system, and using HTML5 controls should alter only this internal gain system.

Hi, maybe can help to better find out the source of the problem.
I beging experiencing this bug ONLY after i upgraded from debian buster to debian bullseye.
Pulseaudio change from:
12.2 -> 14.2

Regards, Alberto.

Im experiencing the same issue but with Debian(bullseye)+Kde and netflix, everytime you pause and the restart a movie the audio get reset to 100%

Honestly, the best approach would be having a setting in about:config "do not alter volume"

Same problem involves both Midori and Gnome Web (was Epiphany), WebKit engine browsers. And confirm that Chrome is not affected.
(Hope this can help further, because problem is quite annoying.)

Please look at:
https://github.com/mozilla/cubeb-pulse-rs/pull/53/files#diff-4e446a2e6b4bdb3c1be55ef9b44ec4a2b1c04c15865a0fde7680d342b065a36aL640

Debian buster pulseaudio 12.2 default to:
flat-volumes = yes

Debian bullseye pulseaudio 14.2 default to:
flat-volumes = no

I tried changing bullseye pulseaudio conf back to "flat-volumes = yes" and problems disappeared!

I think we need to change code to always:
"apply our own gain instead of changing the input volume on the sink. "

and not only when pulseaudio is configured to use flat-volumes.

Regards, Alberto.

(In reply to mello+github from comment #58)

Please look at:
https://github.com/mozilla/cubeb-pulse-rs/pull/53/files#diff-4e446a2e6b4bdb3c1be55ef9b44ec4a2b1c04c15865a0fde7680d342b065a36aL640

Debian buster pulseaudio 12.2 default to:
flat-volumes = yes

Debian bullseye pulseaudio 14.2 default to:
flat-volumes = no

I tried changing bullseye pulseaudio conf back to "flat-volumes = yes" and problems disappeared!

I think we need to change code to always:
"apply our own gain instead of changing the input volume on the sink. "

and not only when pulseaudio is configured to use flat-volumes.

Regards, Alberto.

Thanks! this is helpful!

Paul, do you have a cycle to check if this works?

Flags: needinfo?(padenot)

edited /etc/pulse/daemon.conf to set flat-volumes to no. ran pulseaudio -k (which stops and restarts pulse). visited a youtube video, played with volume. Pulse playback volume is modified by HTML5 video volume control.

edited /etc/pulse/daemon.conf to set flat-volumes to yes ran pulseaudio -k (which stops and restarts pulse). visited a youtube video, played with volume. Pulse playback volume is modified by HTML5 video volume control.

I do not have ~/.pulse or ~/.config/pulse/*.config

in short: I can't see any difference arising from this setting, even though I agree that from its description it ought to work.

maybe you already have done it, but i had to restart firefox to have it fixed.

That does indeed fix it. Still agree with C.M. Chang: "apply our own gain instead of changing the input volume on the sink. "

I can confirm with Kubuntu 21.10 (Pulseaudio 15.0). I set the youtube tab volume to 100% and whenever I reload the tab (I can always reproduce with reloading the tab but not always with pausing the video) the sound goes back to 79% (minutes ago it was 83% for some reason, not it's 79%)
Changing (flat-volume = yes) made the problem worse. Now the sound of firefox is "connected" to my main sound. So every time I pause the video and play it again, firefox' sound goes back to 79% and the speaker's volume goes up to 79% too (so the sound will get really loud). Lowering the speaker's sound (with the buttons from the keyboard) also lower's Firefox' application sound. And when I pause and resume, both go up again to 79%.

P.S: I tried Microsoft edge and I couldn't reproduce there. But Firefox with 79% is way more louder (and better) than 100% with Edge.

I can confirm it's happening on current Debian testing (Bookworm) using Mozilla's Firefox build (96.0b6). PulseAudio is running on Pipewire.

Can also confirm that this is still an issue running Firefox 95.0.2 (64-bit) on Arch linux. Pulse audio itself is running Version 15.0

See Also: → 1747735

This is so annoying. It is the only app that does this. I have always been a Firefox user (since beta 0.7), but this is kinda a deal breaker. Please, fix.

I use openSUSE Tumbleweed with Mozilla Nightly. I'm currently using pipewire with wireplumber. The only way I can control Firefox is by setting media.volume_scale to some value around 0.3 that way the volume only increases to ~70% each time something new is played.

So is the above fix going to be added to Firefox?

Simple workaround for my needs was to set media.volume_scale to 1.7 in firefox's about:config page. This will assure that the volume will always stay at 100% whenever you reload the tab or scrub through a video/audio.

For me this behaviour is fine cause i want firefox to stay at 100% volume and i can change the master volume for the whole system via keyboard.

You can experiment with different values of media.volume_scale to get one fixed volume that fits your needs.

Severity: normal → S3
OS: Unspecified → Linux
Hardware: Unspecified → All

The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:padenot, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(padenot)

This has been reported 4 years ago and it's still an issue. I suggest to just ignore it and build a new decent audio stack on Pipewire.

But sadly I think Chromium will be the first browser in the next years to have native Pipewire support while Firefox will still rely on old Pulseaudio, maybe with this bug still open. Which unfortunately is one on many reasons why Firefox is losing market share.

Is this ever gonna be fixed ?

OpenSUSE tumble weed watching a play list on you tube.

Every freaking time , a new vids starts the volume increases.

Why can't fire fox leave my system volume alone ?

Are the firefox people trying to get me deaf, or are they trying to kill my headset ?

Don't wanna be rude, but I totally don't get why fire fox is resetting and or changing the volume.

For those that don't know OpenSUSE tumble weed, its a rolling release, so I am on the latest firefox version.

How can this have a low severity ?

Hello fellow frustrated Firefox users, a permanent actual (not just setting volume_scale) workaround for this is creating a UserScript for this. For those who don't know what a UserScript is, it is just a script ran when the page loads by a UserScript extension, like ViolentMonkey. Here is the UserScript I made to permanently set YouTube's volume to 100%:

// ==UserScript==
// @name        Fix PulseAudio Volume
// @namespace   Violentmonkey Scripts
// @match       https://www.youtube.com/watch?v=*
// @grant       none
// @version     1.0
// @author      -
// @description 4/29/2022, 6:22:50 PM
// ==/UserScript==

const VOLUME_CHANGE_HANDLER = () => document.querySelector(".video-stream").volume = 1.0;

window.addEventListener("load", () => {
  let videoStream = document.querySelector(".video-stream");
  videoStream.addEventListener("volumechange", VOLUME_CHANGE_HANDLER);
  videoStream.addEventListener("play", VOLUME_CHANGE_HANDLER);
  VOLUME_CHANGE_HANDLER();
});

I don't understand why it can't be fixed in the code proper. Is anything blocking it?

Unsure if this will help to anyone - but since I've been looking into the BZ while seeking solution for my problem, here it goes:

I've spotted similar problem on my Rawhide - after 'playing' for a while with the 'easyeffects' app it happend that with each played 'youtube' video volume dropped to 0 (I'm using pipewire and I'm really unsure how I've got to this mode). But it's been highly annoying that after each song I'd to manual set volume back to 100% in 'pavucontrol' app. I've found the above mentioned script - but since I knew it's been playing before normally I've been seeking for better solution.

Even full system reboot did not helped at all. I've checked all about:config 'media.*' settings - they were in its defaults.
I've also noticed while playing the 'volume control' within Youtube player was not working at all.

Then I've 'flipped' the volume mute icon on the individual firefox's tab On/Off - and all of sudden functionality got restored back to normal - no need to set volume after each song, volume level is preserved properly.

firefox-100.0.2-2.fc37
pipewire-0.3.51-2.fc37

Maybe this helps to some....

(In reply to Hugo van de Kuilen from comment #73)
Modifying your code to dynamically adjust the pulseaudio volume to be what the youtube player actually says it is.

// ==UserScript==
// @name        Fix PulseAudio Volume
// @namespace   Violentmonkey Scripts
// @match       https://www.youtube.com/watch?v=*
// @grant       none
// @version     1.0
// @author      -
// @description 7/15/2022, 12:03:50 AM
// ==/UserScript==

const VOLUME_CHANGE_HANDLER = () => {
  const wrongVolume = document.querySelector(".video-stream").volume
  const trueVolume = document.querySelector("#ytd-player").player_.getVolume() / 100;
  console.log('wrong volume', wrongVolume);
  console.log('true volume', trueVolume);

  document.querySelector(".video-stream").volume = trueVolume;
}

window.addEventListener("load", () => {
  let videoStream = document.querySelector(".video-stream");
  videoStream.addEventListener("volumechange", VOLUME_CHANGE_HANDLER);
  videoStream.addEventListener("play", VOLUME_CHANGE_HANDLER);
  VOLUME_CHANGE_HANDLER();
});

Hi there,

I don't pretend to help, but

For me it's not a bug, when i open Deezer for example, if i enable "Normalize audio niveler" option, yes The Firefox volume is automatically adjusted, but when i disable this option, the volume stays to 100%.

I use Kubuntu 22.04.1 LTS.

Si for me it's a feature for normalize audio level to a constant level.

Why had nothing happened to fix this mess in FIVE YEARS ?

I never had this issue until this week. ( Fedora 35 LCDE spin; ffx 102; pipewire-0.3.56 )

I use a little taskbar widget to adjust sound levels. Once I set it it is constant and applies to all videos. All has been good until yesterday when I needed to use Audacity to edit some sound files. This says it needs Jack and seems to auto start it. In this case it seems to start pipewire which seems to be some kind of jack substitute.

Once I do that the "mixer" widget does not work any more and I have the kind of volume issues described above.

To set output volume I have to fire up PAVC. This lets be set the volume for the video but it seems to close the device and open a new one on each video and resets it to 100%. Worse, if I skip to different part of the same video, it resets the volume ! Also I watch a video clip in Twitter which is get to loop: every loop restart it resets the volume.

This is damned annoying and UNWORKABLE.

If I reboot I get the mixer widget back working .... until I run Audacity or PAVC.

What is this mess and why does it not get fixed?

The fix has already been noted above, but seems to implicate an interaction between the Firefox audio gain management design and a bug in at least one version of pulseaudio.

With the correct version of PA, setting "flat-volume" to one of the two possible values ("no" and "yes") will solve the issue.

On my system, at some point, setting PA to use "flat-volume = no" made everything work as I expected (and it used to be)

Thanks Paul, could you explain what you did for 'setting "flat-volume" to one of the two possible values ' ?

I had found that kind of solution and aped the suggestion:
echo 'flat-volumes = no' >> ~/.config/pulse/daemon.conf

It made no difference at all. I have no idea if that is correct for Fedora , out of date , or anything else.

I think after switching from PulseAudio to Pipewire + Pulse plugin this bug doesn't occur to me anymore, or at least I didn't notice it so far. So it's potentially another option to avoid it.

Thanks for the tip. What is this "pulse plugin" you refer too. Could give a package name?

In Debian testing I got pulseaudio package removed and now I only have a bunch of pipewire packages.

The plugin one is pipewire-pulse (0.3.59).

Thanks, on Fedora that's called pipewire-pulseaudio. I already had that installed. :(

From here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Migrate-PulseAudio

flat flat-volumes should be always off with Pipewire.

Pulse related config can be found in /usr/share/pipewire/pipewire-pulse.conf

OK, I just encountered this bug again with Youtube in particular. So scrap the above. Not sure under what conditions it occurs though.

If according to above it's not a bug in Firefox, should I open a pipewire-pulse bug?

Correct , this is NOT a bug in Firefox.

The problem is seen in PAVC. Each time the an audio track ends , the source is removed from PAVC. The next time the same instance of FFx starts a new audio stream, a new device appears in PAVC with a new ( default ) volume of 100%. This included if I skip back 15s in the same video in FFx.

I imagine that PAVC is just reflecting underlying changes in pipewire, so it may be a more an issue with the underlying way data is streamed than the way PAVC is handling it. Someone with more understanding will need to determine that.

I have installed pssystray which at least gives me a more accessible volume control than swapping to PAVC every 30s to adjust volumes. The previous "mixer" applet which did volume control is now totally without effect.

correction : pasystray

This bug has nothing directly to do with pipewire. It occurs with the "pure" PulseAudio implementation too.

As is evidenced by the fact that the bug was logged 5 years ago before pipewire existed.

You know im really sad this hasn't been touched upon, im having the same problems with Artix Linux, KDE Plazma and pipewire, but ive found that this

https://gist.github.com/abec2304/2782f4fc47f9d010dfaab00f25e69c8a

script works well for nuking youtube's loudness normalisation, snippets that have been posted here didn't work on new "rounded" layout. Really disappointed by mozillas actions here, hope somebody finds this useful.

Given that none of the workarounds suggested in this lengthy bug report appear to resolve the issue I've finally just quit using FF on YouTube. MS Edge for Linux does not suffer from this blight so I've adopted it for the sole purpose of watching YT. Firefox is still my daily driver since the Phoenix days and I'll continue to evangelize it overall as the best browser available. Among the very few long-persisting unresolved issues in FF this one alone causes me serious pain as a user and renders this browser unusable for this particular use-case (watching YT streams at a consistent volume).

If desired I'd love to provide any meaningful and useful diagnostics and debugging information to @padenot

See Also: → 1803721
See Also: → 1746799
See Also: → 1049480

(In reply to tekstr1der from comment #93)

Given that none of the workarounds suggested in this lengthy bug report appear to resolve the issue I've finally just quit using FF on YouTube. MS Edge for Linux does not suffer from this blight so I've adopted it for the sole purpose of watching YT. Firefox is still my daily driver since the Phoenix days and I'll continue to evangelize it overall as the best browser available. Among the very few long-persisting unresolved issues in FF this one alone causes me serious pain as a user and renders this browser unusable for this particular use-case (watching YT streams at a consistent volume).

If desired I'd love to provide any meaningful and useful diagnostics and debugging information to @padenot

I second this. I love FF but this is just unbearably frustrating to say the least. I just want to play a series of music videos while doing dishes without having to come back to my desktop because the volume changes with every video.. Because of this I also feel forced to use Chrome or Edge just for playing YT vids which is just stupid. Might as well make the switch permanently until this get fixed.

That said, If you guys are in need of diags and logs and what not, I would also be happy to provide some as well cause I'd rather stick to FF as my only browser.

After some messing with pavucontrol and I did manage to get this sorted. Not sure that I can say exactly how.

Something about setting which audio channel is "default" and then FFx and others use it and it seems consistent.

Currently using Fed36 , Ffx108.0.1 and pipewireplumber.

IIRC it is still a mess as far as getting it to use a headset mike as input. It keeps defaulting to using the audio stream , if one is playing. Clearly it is trying to be far clever that it really is about "thinking" it knows what I want/need to do and trying to double guess me instead of just leaving things the way I set them.

I've also found this bug to be highly annoying. YT volume in the tab is always set to 100% however if I open pulseaudio I can see the actual volume anywhere from 50-90%. I then have to drag it manually to 100% in pulse. This now requires me to keep the pulseaudio dialog open so I can set the volume for every single video that plays. A waste of time. This bug was opened 5 years ago, this is very silly that this is still a problem.
Some claim it can't be a FF bug however it's the only application that has this problem. Everything else including other browsers work just fine. Something FF is doing audiowise is causing this problem.
Maybe if more budget was focused on fixing problems with the browser itself FF wouldn't be floundering like it is bleeding off users. It's sad too since it's the only option that isn't chrome based these days.
If logs are needed they just need to be asked for. It happen for every video I play on FF.
System information.
FF 110.0 (64-bit)
Operating System: Fedora Linux 37
KDE Plasma Version: 5.27.1
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.13-200.fc37.x86_64 (64-bit)

"Something FF is doing audiowise is causing this problem."

I would say more like something FF is doing audiowise is TRIGGERING this problem." That does not mean FFx is responsible.

Off the top of my head I think FFx is doing something like spawning a new process each time and this is seen as a new program instance which the new pulseaudio widgets are resetting each time. Other browsers may have a single audio device which remains open as long as the browser session is running.

Is see several processes like this running under FFx and AFAIK this is some kind of sandboxing of each tab as a security measure.
/usr/lib64/firefox/firefox -contentproc -childID 9213 -isForBrowser

Like I said above, I got around this by fiddling with pavucontrol and setting default channel or some such, so that it opens the new audio device with my chosen 70% volume instead of 100% each time. I don't have an exact method since I'm just going from memory of a lot of messing about.

The part confusing me as a simple user, is that this is still happening with pipewire too.

openSUSE thumbleweed.

It does however not happen in QMMP (a music player) it only happens with FF.

Maybe I am gonna try opera, because I do get the feeling the FF devs don't care.
This is a Five year old bug.......

IIRC my problems started when I did a Fedora distro upgrade and got stuffed with pipewire. I wasted about a week trying to find out what was wrong and get usable audio back.

IMO that (pipewire) is where the actual bug is. It seems to be trying to be far more clever than it's able and thinks it "knows" what you want/need to do and tries to think for you.

If QMMP just opens one audio stream ( which it likely does ) then that could explain the difference. Whinging and "threatening" to use a different browser is unlikely to change the amount of time FFx crew spend on your naive assumptions about where the problem lies. I've suggested you look at pavucontrol . If you do not have that pkg installed , I suggest you install it and try.

I still have issues with pipewire but at least I have a working FFx.

I am not threatening anybody.

I am starting to loose hope this will be fixed.

I installed pavu control and that did not change a thing.

media.default_volume is set to 0.5

Still on you tube volume jumps to 100% everytime.

Just want to add, that the presented workaround works fine for me too:

Environment: Debian Bullseye / KDE / Firefox 102.8.0esr

  1. Change pulse audio setting in /etc/pulese/daemon.conf flat_volume = yes
  2. Stop pulse audio server as logged in user pulseaudio -k
  3. Stop and Start again firefox

My mouse scroll button over the taskbar widget adjusts a global Builtin Audio Analog Stereo. I find this as a readout only under Default Sink submenu on the context menu of the widget. It is showing 18%.

In pavucontrol Output Devices tab , Builtin Audio Analog Stereo is set to Line-out.

Under playback tab, I see firefox ( when streaming a video ) set at 97% and linked to Builtin Audio Analog Stereo.
If I start a new tab in Firefox and play a new video it gets a new entry in playback tab and is set to 100%.
Each new video streaming in Ffx gets a new entry set at 100%.

All these play at same volume due to 18% setting on the default sink.

That seems logical, stable and works for me as a user.

(In reply to Tobias from comment #102)

Just want to add, that the presented workaround works fine for me too:

Environment: Debian Bullseye / KDE / Firefox 102.8.0esr

  1. Change pulse audio setting in /etc/pulese/daemon.conf flat_volume = yes
  2. Stop pulse audio server as logged in user pulseaudio -k
  3. Stop and Start again firefox

Your workaround works for PulseAudio but not for PipeWire.
Because PipeWire does not support flat_volume.
So Firefox itself should solve this problem.

"So Firefox itself should solve this problem."

how do you expect Firefox to take control of they audio subsystem on your computer ?!

The problem is that Firefox chooses to use "the audio subsystem" to control volume rather than applying gain internally. Instead of scaling the samples in its output to the audio subsystem, like 99% of other applications with audio output, it outputs the raw sample stream (at least in terms of volume) and then uses the audio subsystem API to adjust volume. This is such a wacky idea, and it's the heart of the problem (or was, the last time I looked at it).

Flags: needinfo?(crazylegoguy)
Flags: needinfo?(crazylegoguy)

I am no longer using pulse audio because I swapped to jack after putting in this bug and I’m currently using pipewire. Both of these other audio systems do not exhibit this bug. Sorry I can’t help with reproducing this issue and verifying if it’s fixed

I get this bug with pipewire. Even pausing and playing the video resets firefox's volume. Idk why so many people are saying it is not a firefox bug when other browsers like chromium do not have this issue. Its certainly firefox that is at fault here

Yes, I'm getting the same problem with Firefox using EndeavourOS and pipewire. Playing random Youtube music videos causes the application volume to keep changing. It's so annoying! Chromium plays the same videos without issue.

idk what changed, but audio is somehow persisting with latest nightly on manjaro kde. Using pipewire 1:0.3.70-0

(In reply to crazylegoguy from comment #107)

I am no longer using pulse audio because I swapped to jack after putting in this bug and I’m currently using pipewire. Both of these other audio systems do not exhibit this bug. Sorry I can’t help with reproducing this issue and verifying if it’s fixed

I'm getting this issue with Firefox 112.0.1 from Flathub on Kubuntu in Plasma with Pipewire 0.3.65 (I also have the same problem with the Snap install, so its not a Flatpak issue).

As far as I can tell, the issue is that Firefox sets the volume level directly on the stream the the Linux audio API (PA or PW) and never reads the volume back - so if one uses one of the system tools to change the "application volume" (actually, the specific stream volume, but it gets confused really easily - more on that later), Firefox will ignore that and reset the volume to what it was originally set when reopening the stream. This happens during seeking and when starting a new video (which again - gets complicated, more on that later) but - at least for me - not when pausing and unpausing after a short break.

There are a few additional complications:

  1. YouTube and various other sophisticated players have a volume setting in the HTML player and will remember the volume the user has set in Firefox and will reset to it when doing things like reloading the player or switching to another video; while other players may not set the volume and will start at a 100%.
  2. Even if an HTML player remembers the volume, and Firefox will read the volume change initiated by system tools and advertise it to the player (using the volumechange event) - the player may ignore this event and reset the volume at some later date, surprising the user.
  3. Some system tools - like Plasma's task manager - set an "application level" volume which gets really messy really quickly. Specifically for Plasma's task manager, what it appears to be doing is showing the user the level of the stream with the highest volume, and when the user changes to volume, it scales all the streams in the amount that was changed: so if, for example, the browser has two streams, one set at 100% and one set at 50%, Plasma will show 100% volume, then the user sets 50% volume and Plasma will set the streams to 50% and 25% respectively. If the louder stream then stops and restarts at 100%, Plasma will show the application back to 100% and when the user sets 50% volume - Plasma will set the streams to 50% and 12.5% volume. Lather rinse repeat and it quickly becomes a huge issue.

The last problem is probably too complicated to be solved by Mozilla alone and I'm probably going to take this up with Plasma developers, but for all the other issues, Mozilla can rather quickly improve the user experience and should:

Firefox should definitely read back the stream value back from the system(*) and expose the current volume through the HTMLMedidElement.volume attribute and the volumechange event. I have verified that Firefox 112 does not do that currently.

At the very least it will solve the problem of users getting their volume reset by seeking, and if the HTML player is implemented correctly, it will also solve the problem of changing streams in the same service.

I also think that Firefox should also honor the volume set by the user using the system tools and when creating a new stream it should set the initial volume to the highest volume of any existing streams and/or the last volume set by system tools, to prevent loud audio blasting out at a user at the most unexpected time.

*) I'm not familiar with the PA API and whether it has volume change callbacks - I'm pretty sure it does, but slow polling would also likely be good enough.

I finally switched over from pulseaudio to pipewire about a month ago.

Indeed I should have tested pipewire prior to my comment #93. At least I got to try Edge for a year to view YT vids and it was solid throughout.

This issue has never once occurred again since the switch to pipewire with YouTube on FF. Software volume stays exactly where I set it (100%) in all cases.

I still experience this issue with pipewire 0.3.65-3 (on Ubuntu lunar). Here is a video demonstrating the problem with a non-Youtube player (the straightforward problem, not the complicated Plasma multi-stream-single-knob issue)

Yeah, still happens here with Arch-based distros (e.g. Manjaro) and Pipewire 0.3.84.

I think I noticed one pattern. When opening individual Youtube videos volume level works fine, but when playing a Youtube playlist, volume gets messed up (like being reduced from 100% after it switches the track).

I glued together a couple of scripts I found online and created this Tampermonkey solution. It grabs the volume level from UI slider and applies it to the actual video. This will completely overcome the volume normalization.
It also makes the volume level exponential, so replace Math.pow(slider_volume / 100, 3); with slider_volume / 100 if you don't want that.

// ==UserScript==
// @name         Fuck YouTube Normalization
// @namespace    http://tampermonkey.net/
// @version      v0.Yo.Mama-poops
// @description  I don't know this garbo lang
// @author       adamnejm
// @match        https://www.youtube.com/*
// @match        https://youtube.com/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    function get_fake_volume(){
        var slider = document.getElementsByClassName("ytp-volume-panel")[0];
        if (slider) {
            var slider_volume = Number(slider.getAttribute("aria-valuenow"));
            return Math.pow(slider_volume / 100, 3);
        } else {
            return 0;
        }
    }

    const {get, set} = Object.getOwnPropertyDescriptor(HTMLMediaElement.prototype, 'volume');
    Object.defineProperty(HTMLMediaElement.prototype, 'volume', {
        get(){
            return get_fake_volume();
        },
        set(originalVolume){
            setTimeout(() => {
                set.call(this, get_fake_volume());
            }, 0);
        }
    });

})();
Flags: needinfo?(padenot)
Flags: needinfo?(padenot)

Is anything happening with this?
Or does someone have a surefire way of forcing firefox on a different audio sink where the volume doesn't reset to whatever obnoxiously high value it wants to be set at?

I have the volume automatically set to 95% whenever I play a new video on firefox. It resets automatically even if I change it through pavucontrol manually. The system volume is 100% but I would like to boost firefox volume persistently.

I'm on Mozilla Firefox 131.0

Is there any update on this bug? It's the one thing keeping me from using firefox as my daily driver.

I'm currently using a separate virtual sink as a workaround to this issue, might be useful to some people:

context.modules = [
    {
    	name = libpipewire-module-loopback
        args = {
        	audio.position = [ FL FR ]
        	node.description = "Media Loopback"
            capture.props = {
            	node.name         = "media-sink"
            	node.description  = "Media Sink"
                media.class       = "Audio/Sink"
                node.passive      = true
            }
            playback.props = {
            	node.name         = "media-source"
            	node.description  = "Media Source"
            	node.passive      = true
            }
        }
    }
]

Save this as ~/.config/pipewire/pipewire.conf.d/20-media-sink.conf and restart pipewire with systemctl --user restart pipewire pipewire-pulse wireplumber. After that you should be able to Firefox to that sink with an app like PavuControl or KDE Sound Settings and control volume of the sink instead of the application itself.

(In reply to Name from comment #121)

I'm currently using a separate virtual sink as a workaround to this issue, might be useful to some people:

context.modules = [
    {
    	name = libpipewire-module-loopback
        args = {
        	audio.position = [ FL FR ]
        	node.description = "Media Loopback"
            capture.props = {
            	node.name         = "media-sink"
            	node.description  = "Media Sink"
                media.class       = "Audio/Sink"
                node.passive      = true
            }
            playback.props = {
            	node.name         = "media-source"
            	node.description  = "Media Source"
            	node.passive      = true
            }
        }
    }
]

Save this as ~/.config/pipewire/pipewire.conf.d/20-media-sink.conf and restart pipewire with systemctl --user restart pipewire pipewire-pulse wireplumber. After that you should be able to Firefox to that sink with an app like PavuControl or KDE Sound Settings and control volume of the sink instead of the application itself.

This didn't work for me. Firefox's volume is still reset when changing to a new point a youtube video.

(In reply to Patrick Collins from comment #122)

(In reply to Name from comment #121)

I'm currently using a separate virtual sink as a workaround to this issue, might be useful to some people:

context.modules = [
    {
    	name = libpipewire-module-loopback
        args = {
        	audio.position = [ FL FR ]
        	node.description = "Media Loopback"
            capture.props = {
            	node.name         = "media-sink"
            	node.description  = "Media Sink"
                media.class       = "Audio/Sink"
                node.passive      = true
            }
            playback.props = {
            	node.name         = "media-source"
            	node.description  = "Media Source"
            	node.passive      = true
            }
        }
    }
]

Save this as ~/.config/pipewire/pipewire.conf.d/20-media-sink.conf and restart pipewire with systemctl --user restart pipewire pipewire-pulse wireplumber. After that you should be able to Firefox to that sink with an app like PavuControl or KDE Sound Settings and control volume of the sink instead of the application itself.

This didn't work for me. Firefox's volume is still reset when changing to a new point a youtube video.

If you have a pipewire-pulse.conf file you can add a rule make it auto switch to that sink, I managed to get it working that way; it's still only working around the issue, though.

I'll post more precisely what I did in a follow up in case it's helpful, I'm currently mobile, so don't have it in front of me. But maybe that's enough for you to go on.

(In reply to philipp.leite from comment #123)

(In reply to Patrick Collins from comment #122)

(In reply to Name from comment #121)

I'm currently using a separate virtual sink as a workaround to this issue, might be useful to some people:

context.modules = [
    {
    	name = libpipewire-module-loopback
        args = {
        	audio.position = [ FL FR ]
        	node.description = "Media Loopback"
            capture.props = {
            	node.name         = "media-sink"
            	node.description  = "Media Sink"
                media.class       = "Audio/Sink"
                node.passive      = true
            }
            playback.props = {
            	node.name         = "media-source"
            	node.description  = "Media Source"
            	node.passive      = true
            }
        }
    }
]

Save this as ~/.config/pipewire/pipewire.conf.d/20-media-sink.conf and restart pipewire with systemctl --user restart pipewire pipewire-pulse wireplumber. After that you should be able to Firefox to that sink with an app like PavuControl or KDE Sound Settings and control volume of the sink instead of the application itself.

This didn't work for me. Firefox's volume is still reset when changing to a new point a youtube video.

If you have a pipewire-pulse.conf file you can add a rule make it auto switch to that sink, I managed to get it working that way; it's still only working around the issue, though.

I'll post more precisely what I did in a follow up in case it's helpful, I'm currently mobile, so don't have it in front of me. But maybe that's enough for you to go on.

I'd appreciate if you posted exactly what you did. I'm still relatively new to linux. Thanks!

(In reply to Patrick Collins from comment #124)

(In reply to philipp.leite from comment #123)

(In reply to Patrick Collins from comment #122)

(In reply to Name from comment #121)

I'm currently using a separate virtual sink as a workaround to this issue, might be useful to some people:

context.modules = [
    {
    	name = libpipewire-module-loopback
        args = {
        	audio.position = [ FL FR ]
        	node.description = "Media Loopback"
            capture.props = {
            	node.name         = "media-sink"
            	node.description  = "Media Sink"
                media.class       = "Audio/Sink"
                node.passive      = true
            }
            playback.props = {
            	node.name         = "media-source"
            	node.description  = "Media Source"
            	node.passive      = true
            }
        }
    }
]

Save this as ~/.config/pipewire/pipewire.conf.d/20-media-sink.conf and restart pipewire with systemctl --user restart pipewire pipewire-pulse wireplumber. After that you should be able to Firefox to that sink with an app like PavuControl or KDE Sound Settings and control volume of the sink instead of the application itself.

This didn't work for me. Firefox's volume is still reset when changing to a new point a youtube video.

If you have a pipewire-pulse.conf file you can add a rule make it auto switch to that sink, I managed to get it working that way; it's still only working around the issue, though.

I'll post more precisely what I did in a follow up in case it's helpful, I'm currently mobile, so don't have it in front of me. But maybe that's enough for you to go on.

I'd appreciate if you posted exactly what you did. I'm still relatively new to linux. Thanks!

The systems I've tried this on including Arch Linux and NixOS, didn't require anything other than switching Firefox to this virtual sink ONCE, it would then stay there forever, even after reboots. You can do this in KDE and probably Gnome settings, but here's the exact procedure for pavucontrol-qt:
0. Create the virtual sink following instructions from my original comment

  1. Open Firefox and play some audio, eg. from a YouTube video
  2. Open PavuControl and navigate to the Playback page
  3. On the right hand side you should see a dropdown listing your sinks, eg. on Starship/Matisse HD Audio Controller Analog Stereo
  4. Click on the dropdown and select Media Sink
  5. Done, now all streams from Firefox will be using that Sink
  6. Make sure to control the volume of the Media Sink, instead of Firefox itself an it'll stay in-place. Firefox cannot modify volume of that sink. You can do that in the Outputs Devices tab, using your desktop environment UI or through CLI like so:
  • through pactl: pactl set-sink-volume media-sink 50%
  • through wpctl: wpctl set-volume $(wpctl status | rg "(\d+).+media-sink" -or '$1') 0.5
    Note that pactl is provided by pipewire-pulse, which provides backwards compatibility for Pipewire.

This script is even useful outside of this Firefox issue, I put all of my media-playing apps in addition to Firefox, such as video and music players, which allows me to control volume of my media system-wide, especially music without affecting other programs, which comes really useful when playing video games. Then I just keep all my apps at 100% volume.

As for needing auto-switch in pipewire-pulse.conf, I have never encountered this, however I can offer one general troubleshooting step you guys can try, which in the past has solved multitude of issues related to Pipewire for me, including speakers being used by default when booting up my PC, auto-mute (disabling speakers when headphones are plugged in) being wonky, auto-switching (apps not being moved to headphones / speakers when changing default sink) not working:
rm -r ~/.local/state/wireplumber/
This will remove your config cache and restore some stuff to their default values, eg. volumes of applications, card profiles, etc. So you'll have to open up Pavucontrol / system settings and reconfigure what you want, but clearing the state cache has been a real life savior when dealing with audio issues on Linux in general.

You see, just switching didn't work for me, hence my impatience on this being fixed XD

So I'm using a Steam Deck which I understand is running Arch Linux (or close enough?), I can very easily be wrong. In any case the issue is something that's persisted over a couple resets/reimagings of the device.

What I've ultimately found works, is adding or changing a bit in my default pipewire-pulse.conf file (in my case located in the /usr/share/pipewire/ directory). Note that this segment/stanza (whatever the correct terminology is) is already in the file for me, so I just had to uncomment or modify some things:

matches = [
            {
                # all keys must match the value. ! negates. ~ starts regex.
                application.name                = "Firefox"
                #client.name                = "Firefox"
                #application.process.binary = "teams"
                #application.name           = "~speech-dispatcher.*"
            }
        ]
        actions = {
            update-props = {
                #node.latency = 512/48000
                target.object = "input.Firefox-Sink"
            }
            # Possible quirks:"
            #    force-s16-info                 forces sink and source info as S16 format
            #    remove-capture-dont-move       removes the capture DONT_MOVE flag
            #    block-source-volume            blocks updates to source volume
            #    block-sink-volume              blocks updates to sink volume
            #quirks = [ ]
        }

So the important bits up there are the application.name = "Firefox bit in the matches section, which should pick that up from any ol' Firefox audio stream, then the target.object = "input.Firefox-Sink" line under update-props.
'Firefox-Sink' is what I've called my sink, of course, so you'd replace that with whatever your sink name is, per the example given by Name in the earlier comment describing setting up the sink itself.

Then restarting the pipewire service should load these changes in, and hopefully you're up and running again.

The only caveat is that despite the documentation or other commenters pointing to particular locations as to where all these files are or should be, I didn't necessarily find them in the same place, so you may need to double-check.

Ah, I should have also mentioned that the 'matches' bit is under pulse.rules in my file. Like I said it's already in there by default so I only needed to amend it.

+1 from me too. Really annoying.

Duplicate of this bug: 1947297

After attempting to use virtual sinks on arch i decided to mess around more with media.volume_scale. When you reach 10.0, I have noticed that the volume doesn't reset. From 1.0 to 9.0 it would scale from 48% to 98% volume, the moment i set it to 10.0 it started working correctly, i tested it with skipping videos on YouTube, opening multiple tabs and closing and opening Firefox.

I've trying to figure out why Firefox changing its Pipewire/KDE audio slider was so annoying and like seeing the trees in the forest it finally it dawned on me: For Firefox this link between web-player and KDE audio slider is only working one way!

What do I mean of course it works both ways?

  • When you change Volume in a Firefox web-player (eg. youtube, mp3 file, vimeo) the real audible volume is adjusted and the KDE audio slider for Firefox is moved accordingly.
  • When you change Volume in the KDE audio slider for Firefox the real audible volume is adjusted but the Firefox web-players volume slider IS NOT updated! At this point both sliders are out of sync!

Yes the volume is adjusted correctly both ways, but Firefox does not update the volume control position of any web-player (audio or video element) when volume is changed from outside of Firefox! Now you might say, ofc Firefox can't update the volume slider for the web-player as there might be Javascript involved. MAYBE Firefox is simply not triggering the onvolumechange event when the Pipewire volume is changed externally and this is an easy fix, but otherwise I feel that this feature is a fundamentally broken design.

On a related note:
Does anybody else have the issue that they cannot reduce the minimal volume using a web-players volume controls in Firefox below a certain threshold (eg. 20-25% in KDE) before the volume is muted instead, while controlling the Volume within KDE allows to go lower without issues.

Priority: P1 → P3

(In reply to ST from comment #130)

After attempting to use virtual sinks on arch i decided to mess around more with media.volume_scale. When you reach 10.0, I have noticed that the volume doesn't reset. From 1.0 to 9.0 it would scale from 48% to 98% volume, the moment i set it to 10.0 it started working correctly, i tested it with skipping videos on YouTube, opening multiple tabs and closing and opening Firefox.

Where exactly do you set media.volume_scale to 10.0?

(In reply to Patrick Collins from comment #132)

(In reply to ST from comment #130)

After attempting to use virtual sinks on arch i decided to mess around more with media.volume_scale. When you reach 10.0, I have noticed that the volume doesn't reset. From 1.0 to 9.0 it would scale from 48% to 98% volume, the moment i set it to 10.0 it started working correctly, i tested it with skipping videos on YouTube, opening multiple tabs and closing and opening Firefox.

Where exactly do you set media.volume_scale to 10.0?

In about:config in the browser.

(In reply to ST from comment #130)

After attempting to use virtual sinks on arch i decided to mess around more with media.volume_scale. When you reach 10.0, I have noticed that the volume doesn't reset. From 1.0 to 9.0 it would scale from 48% to 98% volume, the moment i set it to 10.0 it started working correctly, i tested it with skipping videos on YouTube, opening multiple tabs and closing and opening Firefox.

Thanks. I have achieved the same with media.volume_scale = 2.9.

The default volume level was at 70% for me, trying to increase it 2.9 seems to correspond to about 99 - 100% volume.

(In reply to amithm7 from comment #134)

Thanks. I have achieved the same with media.volume_scale = 2.9.

The default volume level was at 70% for me, trying to increase it 2.9 seems to correspond to about 99 - 100% volume.

Caveat: If I reduce video volume to 0 and increase (within the webpage), this issue pops up again. Volume starts at 56% and stays there.

(In reply to amithm7 from comment #134)

(In reply to ST from comment #130)

After attempting to use virtual sinks on arch i decided to mess around more with media.volume_scale. When you reach 10.0, I have noticed that the volume doesn't reset. From 1.0 to 9.0 it would scale from 48% to 98% volume, the moment i set it to 10.0 it started working correctly, i tested it with skipping videos on YouTube, opening multiple tabs and closing and opening Firefox.

Thanks. I have achieved the same with media.volume_scale = 2.9.

The default volume level was at 70% for me, trying to increase it 2.9 seems to correspond to about 99 - 100% volume.

I wanted to add my confirmation of this solution following the realization below:
(In reply to thomas.hufschmidt from comment #131)

I've trying to figure out why Firefox changing its Pipewire/KDE audio slider was so annoying and like seeing the trees in the forest it finally it dawned on me: For Firefox this link between web-player and KDE audio slider is only working one way!

What do I mean of course it works both ways?

  • When you change Volume in a Firefox web-player (eg. youtube, mp3 file, vimeo) the real audible volume is adjusted and the KDE audio slider for Firefox is moved accordingly.
  • When you change Volume in the KDE audio slider for Firefox the real audible volume is adjusted but the Firefox web-players volume slider IS NOT updated! At this point both sliders are out of sync!

Yes the volume is adjusted correctly both ways, but Firefox does not update the volume control position of any web-player (audio or video element) when volume is changed from outside of Firefox! Now you might say, ofc Firefox can't update the volume slider for the web-player as there might be Javascript involved. MAYBE Firefox is simply not triggering the onvolumechange event when the Pipewire volume is changed externally and this is an easy fix, but otherwise I feel that this feature is a fundamentally broken design.

I'm currently running Linux Mint and have had some problems with audio drivers (Mint packages with PipeWire now) since I was trying to figure out how to make my headphones and speakers more compatible (i.e., auto-switching between the two) on my desktop. Long story short, during that time, I discovered that YouTube (and by proxy Firefox) were consistently not at 100%, no matter how much and where I changed their volume.

I eventually found out that 100% in YouTube's volume slider corresponded (for me) with 79% in pavucontrol - I number I have seen referenced in other forum boards on this issue. This solution worked well for me (so far), and I found that media.volume_scale = 2.5 now puts Firefox, with YouTube specifically, at 100%. From fiddling around with this scale value, I think it's probably on some exponential scaling factor since it's probably analyzing decibels - I mean, as in how much gain/signal strength Firefox is trying to assert to the audio driver - and is not caring about the front-facing percentage we see (hence the discrepancy). I could be wrong, but that was the feeling I got messing around with some of the values as it took less and less scaling to gain more and more "percentage"/decibels from Firefox to the audio driver.

If anyone has any better insight, solutions, and more, I'd love to hear to see if this should be approached as a Firefox issue alone, or a hardware/OS issue. What I mentioned previously about seeing 79% seems to be an indication to an issue on Firefox's end so I just want to add to that consensus on information and go from there.

(In reply to Austin from comment #136)

(In reply to thomas.hufschmidt from comment #131)

The behavior mentioned by Thomas, that uni-directional sync issue, is inconsistent.
I have seen volume in taskbar change (firefox stream) when video volume changes, sometimes only.

In my opinion, firefox should not attempt to sync volumes at all.

This issue might also be specific to FireFox + pipewire. I remember not having any issues with pulseaudio.

At this point I have started using Brave browser. This is issue is still at P3 priority.

If anyone needs it, I've modified Name's script from comment #117 for YouTube Music, as that was also suffering from the same issue.
Please note I've removed the exponential volume, so add it back as it was in that comment if you want it. All I did was find the appropriate element for Music and substitute it in. Both work great for me using ViolentMonkey.

// ==UserScript==
// @name         Fuck YouTube Normalization - Music Edition
// @namespace    http://tampermonkey.net/
// @version      v0.Yo.Mama-poops-a-lot
// @description  I don't know this garbo lang either
// @author       adamnejm
// @match        https://music.youtube.com/*
// @match        https://www.music.youtube.com/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    function get_fake_volume(){
        var slider = document.getElementsByClassName("slider-knob-inner")[0];
        if (slider) {
            var slider_volume = Number(slider.getAttribute("value"));
            return slider_volume / 100;
        } else {
            return 0;
        }
    }

    const {get, set} = Object.getOwnPropertyDescriptor(HTMLMediaElement.prototype, 'volume');
    Object.defineProperty(HTMLMediaElement.prototype, 'volume', {
        get(){
            return get_fake_volume();
        },
        set(originalVolume){
            setTimeout(() => {
                set.call(this, get_fake_volume());
            }, 0);
        }
    });

})();

(In reply to Sinkerine from comment #28)

Repro with Firefox 84.0 on Arch Linux. A mitigation that works for me is to tweak the media.volume_scale option in about:config.

This "fixed" my problem with firefox 137 on MX linux. Since i always hold firefox on around 10% of the volume i had to find magic number to make this happen. For me is 0.035 but it will probably depend on your setup

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

Attachment

General

Creator:
Created:
Updated:
Size: