I started a discussion in Devel mailing list
about disabling PulseAudio's flat volumes.
I attach here only the first message. We would need the PulseAudio mantainers to read the discussion and provide us their point of view about this problem.
Thank you very much
Definition of flat-volumes from  : it scales the device-volume with the volume of the "loudest" application. For example, raising the VoIP call volume will raise the hardware volume and adjust the music-player volume so it stays where it was, without having to lower the volume of the music-player manually.
Today I had a scary experience with the audio of my computer.
I was listening to music with Amarok, using my headphones... The KMix volume level was ~ 35%. When I logged into a video conference application, the volume suddenly reached the 100%. I was shocked, having the maximum audio level shooted in your ears is a painful experience.
The conference application that triggered PulseAudio pushing volume to maximum level probably should have never asked the system for a 100% audio level, but on the other hand, PulseAudio should never allow an application to make such sudden changes.
To avoid that, you have to set
flat-volumes = no
I found many users stories complaining about this default setting    and you can easily find other by searching "pulseaudio flat volumes".
I completely agree with user gaggra comment at 
<<This is an interesting issue because it is one of the rare times misbehaving software can physically hurt you. You would think that once that was understood, the design of this sort of behaviour would be treated in a very conservative, careful manner.>>
Moreover this default setting can cause sound crackling .
So I would like to start a discussion about disabling this default behaviour for the mentioned reasons.
I see you filed this against f22, I'm very much against changing default behavior in released fedora versions.
Can consider for unreleased, f23+ though. marking as such.
I have a problem with the usability of non-flat volumes and the 2 volume controls. In the end it also does not solve anything because if you set the master to 100% and then have the clients at 10%, a bad client that asks for 100% is again blasting sound too loud. What you do with non-flat volumes is use the
master volume to limit the volume of the streams.
My opinion is that flat volumes make most sense in the long run but there are currently some features missing to make it perfect:
1) apps can set insane volumes without user interaction
2) some of the logic to lower the master volume if possible is not working like
2) is likely not so difficult to fix but is also not causing trouble, I think.
For 1) we are not quite sure what would be the best thing to do.. Some options include
* limit the volume and ask for confirmation when you want to exceed. Like what
android does. Problem with this is that it sounds weird.
* never allow an app to programatically change the volume. Hard to detect what
is programatical and caused by user interaction from pulseaudio's point of
* fix clients to not set any volume but let pulseaudio and the volume controls
handle the stream volume. This is also difficult because browsers want to
programatically change the volume.
* disable flat volumes for some streams (from browsers). Not quite ideal
because it would require changes to apps and again brings back 2 volume
I can't remember if we ever considered the following option:
* an app can change the volume but never the master volume. Privileged apps
can push the stream volume up to also affect the master volume. The
privileged app would be the pulseaudio control panel or something integrated
in the desktop shell.
At GUADEC, I asked Allan Day to reevaluate the flat volume policy, with the intention that his decision behaves the default upstream in PulseAudio. I sent him this email, but got no useful reply (he was busy with release-preparation work). So here is the text of this email:
Yesterday I promised to mail you some links (including the original paper) about the flat volume issue. Please note that I am inevitably biased towards removing them.
The original Microsoft paper that started all that is here: http://www.patrickbaudisch.com/publications/2004-Baudisch-CHI04-FlatVolumeControl.pdf
Opponents of flat volumes have no published UX research.
The blog post by Lennart Poettering is here: http://0pointer.de/blog/projects/oh-nine-fifteen.html
Let me quote him: "The idea behind flat volumes has been inspired by how Windows Vista handles volume control: instead of maintaining one volume control per application stream plus one device volume we instead fix the device volume automatically to the "loudest" application stream volume."
In other words:
* in non-flat volume model, application-specific volumes are relative to the device volume, which can be adjusted independently;
* in flat volume model, they are absolute, and the "device volume" is just a convenient handle to adjust them all together.
In non-flat volume model, overamplification (i.e. setting the application volume to more than 100%) is permitted. Sounds that are too loud for the current device volume will be distorted and clipped. Such overamplification is sometimes useful when answering a SIP phone call placed by a person with a poor microphone and weak voice. Or when playing poorly recorded videos from conferences.
In flat volume model, one can also raise the softphone or player volume. Loud sounds will then be amplified, too, and reproduced very loudly without distortion.
But then, if a dog barks into the microphone on the other end, I personally would want pulseaudio to clip it instead. Such clipping functionality is only available in non-flat volume model.
In non-flat volume model, the default volume for new applications that cannot be restored from the volume database is 100%. In flat volume model, the default is to copy the device volume (i.e. the volume of the loudest application that was playing recently or is playing now).
Here is a screenshot proving that, contrary to statements from some PulseAudio developers, Windows 7 does NOT actually follow the design from the paper, except for presentation purposes in its mixer applet: http://permalink.gmane.org/gmane.comp.audio.pulseaudio.general/17426
The default volume model in PulseAudio upstream is flat. Ubuntu patches that default back to non-flat.
Despite the claims in the paper, we regularly get confused users in IRC that just don't get why adjusting the application volume can change the system volume. They are assuming these volumes are on top of each other, i.e. have the non-flat model in their mind, and generally are happy when instructed how to switch the volume model.
Application writers don't get it too, because it is not really documented except in the blog post (and, since 2014, in PulseAudio developer documentation). This especially applies to those not using PulseAudio directly, but via wrappers such as GStreamer or Qt that don't document the model and only provide the "volume" property. See e.g.: https://bugreports.qt.io/browse/QTBUG-36511
The most common application bug that is relevant to flat volumes is that they set the stream volume without user interaction to the value that they think is correct, but which isn't. E.g. to 100%, which means "as loud as the sound card can do". See this list of bugs, old and new:
https://bugs.kde.org/show_bug.cgi?id=324975 (that's from 2014! Note especially in https://git.reviewboard.kde.org/r/120796/ that the developer doesn't realize that the fact that he is on Ubuntu is why he cannot reproduce the bug)
https://bugzilla.gnome.org/show_bug.cgi?id=675217 (reproducer: http://jsfiddle.net/bteam/FbkGD/ )
My own opinion is that "after 6 years developers still don't get it right, with dangerous consequences" is a sufficient reason to disable flat volumes, but other developers apparently disagree. The decision that we reached is "we need some attention from an UX expert" - and that's you.
(In reply to Alexander E. Patrakov from comment #3)
> Here is a screenshot proving that, contrary to statements from some
> PulseAudio developers, Windows 7 does NOT actually follow the design from
> the paper, except for presentation purposes in its mixer applet:
To me, it looks like this screenshot implements the idea I posted above. In this case the player is not a privileged app and can only adjust the volume without affecting the system volume (so 0-100 relative to system volume). The mixer app, however, is privileged and can adjust the system volume.
Here's an example of real-world problems flat volumes cause and that the recommended "fix" is almost with no exception to disable it:
"While this is a pretty neat feature, I think that the Pulse Audio developers should either not have enabled it by default (which it is), or made it so that application developers explicitly have to request it (note: I don’t know too much about the sound stack, but if an application triggers this without their intention, I think it might be up for improvement)."
FWIW I hit the YouTube issue all the time. It's extremely frustrating.
We've been talking about this a bit and working out solutions. I hope to have something proposed this week.
Thanks, Arun, looking forward to it :)
(In reply to Arun Raghavan from comment #7)
> We've been talking about this a bit and working out solutions. I hope to
> have something proposed this week.
Hey Arun, have you made any progress on this?
I think if we cannot fix the user experience issues, it's long past time to disable flat volumes, at least until the issues can be fixed.
(In reply to Michael Catanzaro from comment #9)
> (In reply to Arun Raghavan from comment #7)
> > We've been talking about this a bit and working out solutions. I hope to
> > have something proposed this week.
> Hey Arun, have you made any progress on this?
> I think if we cannot fix the user experience issues, it's long past time to
> disable flat volumes, at least until the issues can be fixed.
We've got consensus on how to proceed with this . I've got some of the initial API work we need done already. Not sure we'll have this in time for 8.0 (freeze scheduled for end of this month), but hopefully soon after.
Thanks for the update, Arun. The decision is not what I hoped for (disabling flat volumes by default, or at least make it opt-in for apps, not opt-out, which makes me question how well this will work for random third-party apps), but hopefully it will improve the state of things.
Please note, though, that the new proposal solves just one of the major issues (sudden loudness bursts). There are other major issues we will not get resolved by this, like the fact that apps tend to get lower and lower relative volume over time, and if they have no internal volume control widget, users have no easy way to make them louder. So they end up with system volume to 100% and still not hearing the sound properly (bug 523809). This could be partly resolved by proper OS integration (something like https://extensions.gnome.org/extension/858/volume-mixer/, which is showing a volume bar per playing app, so it's easy and obvious how to restore the max volume even for apps without their own volume widgets), but we currently don't have that in core GNOME or other DE (yes, GNOME has a similar tool hidden in control panel in a specific tab, but people not aware of this issue will never look for it there).
That triggers another major issue, if you have system volume cranked up to 100% just to hear $app whose volume got lowered to 20% over time, and then run a completely new app, it blasts you with maximum volume (equal to system volume by default). It is common for different kinds of background services which emit a beep from time to time (email checking shell extensions, etc). This is not a one time issue because you're unable to set/lower volume for such services, there are no tools for that. This is a different kind of a loudness burst that the patch will not get rid of.
So as far as this ticket is concerned, I'd rather see flat volumes disabled by default in Fedora until major DEs have proper support for it, and the major issues are addressed.
The first problem you specify (lower and lower volumes) is one that I've got on my plate too -- it has to do with device volumes not being reduced in flat volume logic. The specific case in your second example is the same too.
More generally, the problem of applications not having the same loudness will cause the same problem with or without flat volumes.
Missed a couple of things you mentioned: dealing with third party apps is part of the discussion I linked to. Notification sounds do have a volume control (and if an app is emitting notification sounds without tagging them, it needs to be fixed).
Thanks for responses, Arun.
(In reply to Arun Raghavan from comment #12)
> The first problem you specify (lower and lower volumes) is one that I've got
> on my plate too -- it has to do with device volumes not being reduced in
> flat volume logic. The specific case in your second example is the same too.
Great to know this is also being worked on (or at least acknowledged).
> More generally, the problem of applications not having the same loudness
> will cause the same problem with or without flat volumes.
Yes, however, you're much more likely to run with 100% system volume in case of flat volumes (because of the problem mentioned above).
(In reply to Arun Raghavan from comment #13)
> Missed a couple of things you mentioned: dealing with third party apps is
> part of the discussion I linked to.
Sorry, I might not have parsed everything correctly (it's a low level discussion). I was mostly concerned about out-of-repo (often closed source) apps which are not that well known, so they don't end up in a blacklist.
> Notification sounds do have a volume
> control (and if an app is emitting notification sounds without tagging them,
> it needs to be fixed).
My experience is that such apps do appear in the list either in gnome control center or the gnome-shell extension during emitting the beep, but since the beep is very short (1 second or less), they disappear from the list immediately, so I'm not able to grab the slider and lower the volume. It's also not something a general user is able to do (or figure out). I guess internally such apps simply execute something like "aplay sound.wav". If that is a wrong approach (I have no idea), we can try to fix the OSS ones (even though the fact that many widespread OSS apps still don't have PA integration doesn't give much confidence in this plan), but we can't fix the whole world.
However, if we fix gradually lowering volumes, people will not run with 100% system volume so often, and this might become a non-issue.
*** Bug 1298588 has been marked as a duplicate of this bug. ***
*** Bug 1240880 has been marked as a duplicate of this bug. ***
Hi, do we have any update on this? It would be good to know if this will be resolved in time for F24. The Workstation working group prefers to defer to the package maintainers on this issue, but we really want it either fixed nicely or with a workaround (e.g. disabling flat volumes).
I'm personally tired of my ears being blasted every time I start a YouTube video. ;)
This is still in progress. The first set of API patches for per-stream volume control have been posted to the list. When that is done, we will be able to look at controlling per-stream flat volume control.
flat-volumes denies the user the ability to limit volume, and in a world where sound cards can have an incredibly painful (possibly harmful) max volume this is completely unreasonable, negligent even
It only gets worse worse when you consider offloading volume control, to an external amplifier for example
> In non-flat volume model, overamplification (i.e. setting the application
> volume to more than 100%) is permitted. Sounds that are too loud for the
> current device volume will be distorted and clipped. Such overamplification
> is sometimes useful when answering a SIP phone call placed by a person with
> a poor microphone and weak voice. Or when playing poorly recorded videos
> from conferences.
> In flat volume model, one can also raise the softphone or player volume.
> Loud sounds will then be amplified, too, and reproduced very loudly without
> But then, if a dog barks into the microphone on the other end, I personally
> would want pulseaudio to clip it instead. Such clipping functionality is
> only available in non-flat volume model.
Surely these would be better solved with range compression? rather than adjusting the system volume
(In reply to Andrew Cook from comment #20)
> > In non-flat volume model, overamplification (i.e. setting the application
> > volume to more than 100%) is permitted. Sounds that are too loud for the
> > current device volume will be distorted and clipped. Such overamplification
> > is sometimes useful when answering a SIP phone call placed by a person with
> > a poor microphone and weak voice. Or when playing poorly recorded videos
> > from conferences.
> > In flat volume model, one can also raise the softphone or player volume.
> > Loud sounds will then be amplified, too, and reproduced very loudly without
> > distortion.
> > But then, if a dog barks into the microphone on the other end, I personally
> > would want pulseaudio to clip it instead. Such clipping functionality is
> > only available in non-flat volume model.
> Surely these would be better solved with range compression? rather than
> adjusting the system volume
First, in non-flat volume model, the stream volume is adjusted, not system, in this situation. Second, yes, dynamic range compression would be better, if users are able to understand it. But, where to implement it? In all browsers/players/etc? In PulseAudio (and GNOME people will then immediately ban any kind of UI for it)?
For SIP phones specifically range compression seems like a completely sane default, it could either be in the phone or requested for from pulse, makes little difference.
For a generic UI, call it something like "Volume boost", "Loudness boost", or something to that effect. Seems pretty clear what that would do
Just to double check, flat-volumes is when per-stream volumes become absolute rather than relative to the master volume? With the intent of auto-adjusting the master volume for the user
(In reply to Arun Raghavan from comment #18)
> This is still in progress. The first set of API patches for per-stream
> volume control have been posted to the list. When that is done, we will be
> able to look at controlling per-stream flat volume control.
So are you saying that you agree with bug #1298588 ? :) and you are fixing ?
I think that the time is ripe for an escalation of this to FESCo. I will fill a ticket soon.
(In reply to Germano Massullo from comment #26)
> I think that the time is ripe for an escalation of this to FESCo. I will
> fill a ticket soon.
Please do. I'm ok with disabling flat-volumes for now. I would want to enable them again iff:
1) we have a way to provide flat volumes to selected/trusted apps
2) The mixer app can present a flat-volume view of the currently playing streams (or any other redesign of the mixer app that takes flat volumes into account)
This is a Workstation-specific issue and the Workstation working group is tracking it. There's no need for a FESCo ticket unless you're dissatisfied with our progress or eventual resolution.
Anyway, we discussed this issue at this week's Fedora Workstation meeting. My proposal was to require the PulseAudio maintainers to disable flat volumes temporarily until this bug could be resolved, due to the high severity of this issue. The proposal was not approved due to concern over changing this setting temporarily and then back again when this bug is resolved, over the assumed opposition of the package maintainers. Instead, we agreed to ask Wim to prioritize work on this issue, and revisit next month. This decision was affected by our understanding that Wim was opposed to disabling flat volumes, which seems to no longer be the case.
Wim, since you're OK with disabling flat volumes, do you want to just do it? If you're concerned because you're not the primary maintainer for this package, could you discuss with Lennart? Otherwise, we'll revisit this at a Workstation meeting later this month.
I can take care of doing the deed packaging-wise.
Any PA maintainer who objects, feel free to speak up.
* Fri Mar 04 2016 Rex Dieter <firstname.lastname@example.org> - 8.0-4
- RFE: Disable PulseAudio's flat volumes f24+ (#1265267)
For posterity, understand this decision to disable flat volumes is likely only temporary, until issues with it's enablement (outlined within this bug mostly) can be addressed satisfactorily.
Flat volumes are totally broken by design, they should remain disabled forever.
*** Bug 1324790 has been marked as a duplicate of this bug. ***