@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.

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 :)

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.

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)

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.

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.

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%.

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

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.

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.

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.

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.

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.