Volume Step not changeable in Unity and GNOME desktops

Please integrate from gconf2
/apps/gnome_settings_daemon/volume_step
in Oneiric dconf gsettings.

Status changed to 'Confirmed' because the bug affects multiple users.

@Josh Burghandy
On the affected machine, please open a Terminal window (Ctrl+Alt+T) and run this command:
apport-collect 871133
After doing so, please verify that information was automatically attached to this bug report and that the "apport-collected" tag was automatically added (please do *not* manually add it yourself). If this is the case, then you can go ahead and change this bug's status back from Incomplete to Confirmed. The automatically attached information should hopefully make this report complete enough to be worked on by a developer.

@Sam_
Was there additional information you had wanted attached as well? You may want to clarify your request from https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/871133/comments/1.

apport information

done.

ApportVersion: 1.23-0ubuntu3
Architecture: i386
DistroRelease: Ubuntu 11.10
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta i386 (20110921.2)
NonfreeKernelModules: fglrx
Package: gnome-settings-daemon 3.2.0-0ubuntu5
PackageArchitecture: i386
ProcEnviron:
 PATH=(custom, no user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic-pae 3.0.4
Tags: oneiric running-unity
Uname: Linux 3.0.0-12-generic-pae i686
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

apport information

Addendum to #1
Screenshot of volume_step in gconf from Natty.

Which is missing in Oneiric gconf and dconf. (screenshots) I've searched gconf for 'volume' and 'daemon' which didn't reveal any key value 'volume_step', dconf unfortunately can't be searched like gconf (another missing feature, but that's another bug story).

Rolling on the sound icon with my touchpad causes smaller increases in the volume step, although I am constantly fighting to get it to simply increase the volume instead of popup the entire window.
Using the manual volume control wheel on the front of my toshiba laptop, the volume step goes back to the really big steps.

Isn't there another solution to this? I mean, it has to be set by some kind of key/property, right? What's controlling it, if not the key from gconf? I'm being affected too; really liked when it worked.

I found a workaround :D
With the command, you can control the volume: amixer set Master 1- (lower), amixer set Master 1+ (higher)
This commands can be set for the special keys you want: System Settings -> Keyboard -> Shortcuts -> Custom Shortcuts
Here you have to create two new entries: 1. Name: VolumeUp, Command: amixer set Master 2+ (I think '1' is too slow for change). The second one for VolumeDown. Then set the key for running this command by clicking on the line and type, scroll or whatever you want to use for volume-control.

The only thing which don't work is the quick-notifying (this bubble in the top-right corner) which shows the change of the volume.
But now it works smooth as hell :)

Thanks Erik. When using headphones, I really consider this a safety hazard as it is very easy to have the volume turned up too lout, too fast.

zbeefy, apparently the volume step is hard coded.

This is really really anoying because I am using 11.10 as multimedia pc as well (mythtv). Using the standard volume control via the infrared control, it is not possible to adjust a proper volume - especially when watching TV in the evening.

To remove this option in gconf without given a proper alternative is not acceptable. It really should not be such a big thing to add a dconf option for this feature.

Just my 2 cents ;)

I temporarily could solve according to #13, but using "xbindkeys"according to this thread: https://wiki.archlinux.org/index.php/Xbindkeys . As stated above the on screen display for audio is then not visible any more! I like this solution more, because it does not depend on the gui you are using (unity, cinnamon, ...)

"xbindkeys" uses "dB"-steps by default. But you also could use "1%+/-" to toggle the sound.

Be aware that it does not toggle your pulseaudio volume. The "maximum" pulse sound level you can adjust using the "audio settings" dialog.

You can check everything running "alsamixer" in a terminal and the "audio settings" dialog.

I also added the amixer commands to my .lirc configuration.

Steps to reproduce:

1. Install xbindkeys and graphical configuration program (last not really needed for this scenario)

 sudo apt-get install xbindkeys xbindkeys-config

2. Edit a configuration file

gedit ~/.xbindkeysrc

# Increase volume
"amixer set Master playback 1+"
    m:0x0 + c:123
    XF86AudioRaiseVolume

# Decrease volume
"amixer set Master playback 1-"
    m:0x0 + c:122
    XF86AudioLowerVolume

# Toggle mute - this is not used here
#"amixer set Master toggle"
# m:0x0 + c:121
# XF86AudioMute

3. Add "xbindkeys" to the programs that should be started after login

Thanks Axel for finding it!

But I want to see that nice OSD to know how high the volume is so my search continued but then I found this neat shellscript: http://askubuntu.com/questions/12766/adjust-volume-via-commandline-so-that-volume-notify-pops-up

So I changed your ~/.xbindkeysrc so that it posts the volume with the nice notify-OSD also.

It's an ugly hack but hey, it works =)

///////////////////////////////////

gedit ~/.xbindkeysrc

/////

# Increase volume
#"amixer set Master playback 1+"
"sh ~/.volumeHack.sh up -i 2% -m Master"
    m:0x0 + c:123
    XF86AudioRaiseVolume

# Decrease volume
"sh ~/.volumeHack.sh down -i 2% -m Master"
    m:0x0 + c:122
    XF86AudioLowerVolume

# Toggle mute - this is not used here
#"amixer set Master toggle"
# m:0x0 + c:121
# XF86AudioMute

///////////////////////////////////

gedit ~/.volumeHack.sh

//////

#!/bin/sh

usage="usage: $0 -c {up|down|mute} [-i increment] [-m mixer]"
command=
increment=5%
mixer=Master

while getopts i:m:h o
do case "$o" in
    i) increment=$OPTARG;;
    m) mixer=$OPTARG;;
    h) echo "$usage"; exit 0;;
    ?) echo "$usage"; exit 0;;
esac
done

shift $(($OPTIND - 1))
command=$1

if [ "$command" = "" ]; then
    echo "usage: $0 {up|down|mute} [increment]"
    exit 0;
fi

display_volume=0

if [ "$command" = "up" ]; then
    display_volume=$(amixer set $mixer $increment+ unmute | grep -m 1 "%]" | cut -d "[" -f2|cut -d "%" -f1)
fi

if [ "$command" = "down" ]; then
    display_volume=$(amixer set $mixer $increment- unmute | grep -m 1 "%]" | cut -d "[" -f2|cut -d "%" -f1)
fi

icon_name=""

if [ "$command" = "mute" ]; then
    if amixer get Master | grep "\[on\]"; then
        display_volume=0
        icon_name="notification-audio-volume-muted"
        amixer set $mixer mute
    else
        display_volume=$(amixer set $mixer unmute | grep -m 1 "%]" | cut -d "[" -f2|cut -d "%" -f1)
    fi
fi

if [ "$icon_name" = "" ]; then
    if [ "$display_volume" = "0" ]; then
        icon_name="notification-audio-volume-off"
    else
        if [ "$display_volume" -lt "33" ]; then
            icon_name="notification-audio-volume-low"
        else
            if [ "$display_volume" -lt "67" ]; then
                icon_name="notification-audio-volume-medium"
            else
                icon_name="notification-audio-volume-high"
            fi
        fi
    fi
fi
notify-send " " -i $icon_name -h int:value:$display_volume -h string:synchronous:volume

/////////////////////

Nothing yet on this? Where is it hard-coded? If anyone can point me in a direction I'll scour the grounds.

I tried the work-around, but when I do next on rhythmbox, it sets Master to 0 and raises PCM volume meaning that I need to set volume for each song I listen to

This bug is still present in Ubuntu Precise...

As of now in Precise the workaround has stopped working. Right now I'm using an uglier but working solution:

Download and install pulseaudio-equalizer from the repos, and then make an EQ preset where you reduce the volume on all frequencies by some amount, say 12-24 db. What you do is that you will reduce the maximum volume possible thus making each volume step affect the volume less in turn giving you more headroom to play with.

Problem confirmed on my end.

Unfortunately, this link (https://bugzilla.gnome.org/show_bug.cgi?id=650371) shows that devs are unwilling to fix this problem. It's unfortunate, as this problem can cause both hearing and audio equipment damage.

Edit- that came off a little harsh, sorry about that. Maybe we could figure out what needs to be done to fix this in the correct way? Does anybody have suggestions on where a good place to start would be? I'm not a great programmer (yet), but it would be great to see what the right way to fix this issue would be....?

I just looked a bit at the source and how hard to fix should depend on how nice a solution you want. If you only want to change the number of steps it should be enough to change their hardcoded line:

#define VOLUME_STEP 6 /* percents for one volume button press */

to say 2.

Ideally though would be to make it configurable such that VOLUME_STEP is like before in gnome2 is externally configurable.

The problem though is that the Gnome viewpoint is flawed since they have built it for embedded sound systems where the usable volume is from 0% up to 100% but if you use an external sound system then this is usually not the case but rather 20-30 % might me maximum.

On HP laptops which have the capacitive volume adjustment strip, changing volume is very racy.

You probably cannot expect the hard-coded +/- 6% to create a good experience on all systems.

I have an HP laptop and, indeed, the volume steps are so large that after I've decreased the volume just 3 or 4 clicks from maximum, I can no longer hear anything. The weird thing is that even though I can't hear anything and I can see that the Master volume in alsamixer is zero, the volume notification bar is close to maximum. Ugly.

It would be nice if volume_step were availalbe in gconf or mate-conf. In the meantime, I found an elegant workaround...

I was looking for a solution where I'd have BOTH reasonable volume steps AND the nice volume notification bar. I tried many things and went around in circles. This is the only solution that gave me both:

1. In a terminal, type alsamixer then increase Master volume to maximum

2. Change the volume button behavior to control PCM volume rather than Master by editing the /etc/pulse/default.pa and changing this line:
# load-module module-alsa-sink
to this:
load-module module-alsa-sink control=PCM

3. restart

Now the volume buttons control PCM. The steps are nice and the volume bar shows up normally.

Woop woop! Confirmed on Ubuntu 12.04!
After the restart did something funny as I tried to turn the volume down to 0 and then I lost everything.
Run alsamixer again and check for any "MM" label below any channel. This means the channel is muted. Hit m on keyboard to turn "MM" to "00" (means open=working). Once I did this I could turn the volume from my keyboard from all the way down to 0 to 100%.

Thanks bdantas a LOT !!!

Is there any plan on adding a configuration for this again?

It was disabled in https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/media-keys/gsd-media-keys-manager.c?h=gnome-3-6&id=1a9eea8224d41643a8a7a05d799198058e36e1a8

Why was this?

For those who are not afraid of compiling gnome-settings-daemon themselves, have a look at this:
https://bugzilla.gnome.org/show_bug.cgi?id=650371#c42

I'm afraid the people there seem to be ignoring that patch though.

Ubuntu 13.10, Gnome-Shell 3.10.2.1 problem still exists (1 step = 10% change on mouse scroll) and is extremely annoying. Volume step should be configurable or at least less than 10%.

Still exists in Ubuntu 15.10. Please fix this. I've just switched to ubuntu, and this is *really* annoying.

Since the patch attached in the bug report hasn't been accepted upstream (and probably won't ever be), can we please add it to the Debian packaging?

I decided to take some initiative and apply the patch myself. Naturally, it needed to be applied to both gnome-settings-daemon and unity-settings-daemon. The new setting is exposed at "org.gnome.settings-daemon.plugins.sound.volume-step" and can easily be changed with dconf.

I've uploaded the packages to ppa:george-edison55/gnome-settings-daemon

More information about my fix (and instructions) can be found here: http://askubuntu.com/a/704733/5

Status changed to 'Confirmed' because the bug affects multiple users.

I'm attaching the @george-edison55 (Nathan Osman)'s patch to fix the bug here. It's from Nathan Osman's PPA ppa:george-edison55/gnome-settings-daemon - https://launchpad.net/~george-edison55/+archive/ubuntu/gnome-settings-daemon . The PPA contains bugfixed gnome-settings-daemon and unity-settings-daemon packages for Ubuntu 14.04LTS, 15.04 and 15.10. The patch attached here is for gnome-settings-daemon v3.16.3 in Ubuntu 15.10 "Wily Werewolf".

The attachment "Add Volume Step setting for gnome-settings-daemon v3.16.3" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

HEXcube, thanks for taking the time to attaching the patch, however for a fix to be backported into the stable releases it must land in the current development release (Xenial) first. However that said, I mostly agree with upstream here and would not want to see it incorporated into ubuntu except as a last resort, it really is just a hidden magic button that glosses over potentially real bugs.

First I see reports (mostly in the upstream report) that people are getting 10-30% steps in volume instead of the defined 6%. That is clearly a bug, and should be fixed first since it is really unclear how much that is contributing to the reported issues.

Second using a linear scale for a volume slider is really not ideal, pulse audio uses a cubic scale to define volume, but from a quick glance at the source code it may be that g-s-d is plugging linear values into these structures. IF that is indeed true, then it is also going to mess up the actual steps, of the actual audio volume.

@darkxst "𝘵𝘩𝘢𝘯𝘬𝘴 𝘧𝘰𝘳 𝘵𝘢𝘬𝘪𝘯𝘨 𝘵𝘩𝘦 𝘵𝘪𝘮𝘦 𝘵𝘰 𝘢𝘵𝘵𝘢𝘤𝘩𝘪𝘯𝘨 𝘵𝘩𝘦 𝘱𝘢𝘵𝘤𝘩" . Well, I didn't do the patch, just attached the patch done by Nathan Osman (https://launchpad.net/~george-edison55 ). So, it's Nathan who deserves the thanks for working on a fix. 😊

"𝘧𝘰𝘳 𝘢 𝘧𝘪𝘹 𝘵𝘰 𝘣𝘦 𝘣𝘢𝘤𝘬𝘱𝘰𝘳𝘵𝘦𝘥 𝘪𝘯𝘵𝘰 𝘵𝘩𝘦 𝘴𝘵𝘢𝘣𝘭𝘦 𝘳𝘦𝘭𝘦𝘢𝘴𝘦𝘴 𝘪𝘵 𝘮𝘶𝘴𝘵 𝘭𝘢𝘯𝘥 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘶𝘳𝘳𝘦𝘯𝘵 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘮𝘦𝘯𝘵 𝘳𝘦𝘭𝘦𝘢𝘴𝘦 (𝘟𝘦𝘯𝘪𝘢𝘭)". Nathan's PPA (https://launchpad.net/~george-edison55/+archive/ubuntu/gnome-settings-daemon ) contains patched 𝐠𝐧𝐨𝐦𝐞-𝐬𝐞𝐭𝐭𝐢𝐧𝐠𝐬-𝐝𝐚𝐞𝐦𝐨𝐧 and 𝐮𝐧𝐢𝐭𝐲-𝐬𝐞𝐭𝐭𝐢𝐧𝐠𝐬-𝐝𝐚𝐞𝐦𝐨𝐧 for 14.04LTS, 15.04 and 15.10 currently. I've requested Nathan to do a port for 16.04 "𝘟𝘦𝘯𝘪𝘢𝘭".

"...just attached the patch done by Nathan Osman"

I didn't create the patch either, though I did need to tweak it a bit to fix some compilation errors.

"First I see reports (mostly in the upstream report) that people are getting 10-30% steps in volume instead of the defined 6%."

I know this isn't going to carry a lot of weight but I've been running the modified package on my desktop for a couple weeks now and it has worked flawlessly. Volume always changes by the percentage I choose. One important question worth answering is whether the users observing the 10-30% jump modified the value from its default. If users leave the setting at its default value, is behavior any different? If not, then the issue only affects those who change the setting - users who are likely willing to accept the issues anyway.

"Second using a linear scale for a volume slider is really not ideal, pulse audio uses a cubic scale to define volume, but from a quick glance at the source code it may be that g-s-d is plugging linear values into these structures."

The patch doesn't change the expression used for calculating norm_vol_step. It merely replaces VOLUME_STEP with the value from the new setting.

I've linked my branch containing the patch and uploaded a Xenial build of gnome-settings-daemon to the PPA mentioned in my earlier message with the same patch. If the patch is accepted and merged, I will do the same thing for unity-settings-daemon - but I don't want to take the time to do that now if there isn't any chance of this getting accepted.

Oops - I meant to write "If so" instead of "If not" in the fourth paragraph of the last message.

@darkxst

> First I see reports (mostly in the upstream report) that people are getting 10-30% steps in volume instead of the defined 6%. That is clearly a bug......

VOLUME_STEP is defined as 6. It doesn't mean that it will increase by 6% every-time for all hardware. NORM_VOL_STEP is defined as "norm_vol_step = PA_VOLUME_NORM * vol_step / 100;"

@hexcube How did you manage to format text like that? Has launchpad started supporting *text formatting?*

+1
Canonical please add this function on Unity!!!

Still not fixed in 16.04. I just upgraded from Debian wheezy where one nudge of the scroll wheel changed the alsamixer control by a consistent 5dB. This was bad already, because 5dB is too coarse. It feels like a compromise between those who want to use the scroll wheel for fine volume adjustments (which would require a step no larger than 2dB) and those who want to use it as a mute button (see Bug #551725). Unfortunately this compromise benefits nobody, because it falls in between the only two sensible use cases.

The slider behavior in Xenial is worse. The amplitude follows what appears to be a quadratic function. This feels like someone lacking proper knowledge about audio had a go at fixing the previous volume slider that, being a bad compromise, didn't work for anyone. Step size varies depending on the slider position. I use sensitive earphones that are already quite loud with the slider near the leftmost position, where step sizes are about 8dB, which is awful.

Anyone touching code that involves audio, should perhaps first read my rant about software volume controls:
http://www.dr-lex.be/info-stuff/volumecontrols.html

The position of the slider should map linearly to dB values, or in other words the volume multiplication factor must be an exponential function of slider position. It _will_ be unavoidable that for some users the slider will either have a ‘dead zone’ or a ‘too loud’ zone, because the maximum loudness of connected loudspeakers or headphones can vary wildly.

Any interface that changes the volume by discrete increments like volume keys or the scroll wheel, must use fixed dB steps, in other words a fixed multiplication factor for linear amplitude. A good size for this step is 2 dB. To cater for those who only want to use the volume keys or scroll wheel to quickly make huge volume adjustments, the step size should indeed be configurable as this bug suggests. A drop-down menu with values of 1dB, 2dB, 3dB, and 6dB would be sufficient.

"@𝘩𝘦𝘹𝘤𝘶𝘣𝘦 𝘏𝘰𝘸 𝘥𝘪𝘥 𝘺𝘰𝘶 𝘮𝘢𝘯𝘢𝘨𝘦 𝘵𝘰 𝘧𝘰𝘳𝘮𝘢𝘵 𝘵𝘦𝘹𝘵 𝘭𝘪𝘬𝘦 𝘵𝘩𝘢𝘵? 𝘏𝘢𝘴 𝘭𝘢𝘶𝘯𝘤𝘩𝘱𝘢𝘥 𝘴𝘵𝘢𝘳𝘵𝘦𝘥 𝘴𝘶𝘱𝘱𝘰𝘳𝘵𝘪𝘯𝘨 *𝘵𝘦𝘹𝘵 𝘧𝘰𝘳𝘮𝘢𝘵𝘵𝘪𝘯𝘨?*"

@khurshid-alam Sorry for the late reply, but Launchpad doesn't have text formatting yet. I just use a unicode encoder as a workround. 😊 For eg, try http://qaz.wtf/u/convert.cgi?text=khurshid-alam

Now that the bug's fixed on upstream GNOME, it'll eventually make it into Ubuntu's GNOME. And since Unity 7's discontinued, no point in backporting unless for the last LTS running Unity (16.04). In my opinion, the bug's effectively fixed.

How does one use this new feature? Tried to find instructions for it but found nothing. Is it still a dconf setting? If so, where is it located? The same one that Nathan's patch used does not yield any difference in volume steps.

Currently running 17.10 and kernel 4.13.0-32-generic, but not seeing any changes from the bug fix. Does anyone know when this fix will actually get rolled into a package release?

I have the same problems as the previous two posters. Also it seems that the old workaround of using this PPA https://launchpad.net/~george-edison55/+archive/ubuntu/gnome-settings-daemon no longer seems to work.

Can we get a heads-up?

This is an open issue on the project's GitLab: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/474

Still not sure it's getting any attention :( Would really like this feature.

It's fixed in version 3.35. Sadly Ubuntu 19.10 and older will not get the update.

On Ubuntu 20.04 or newer you can change step like this:

dconf write /org/gnome/settings-daemon/plugins/media-keys/volume-step 2