This is probably the wrong way to do it. We currently show and change the volume based on 100%, and a certain number of steps. The size of the steps should be calculated from the maximum dB volume at 100%, so that a volume step feels like a constant increase in volume.

Sounds sensible. Are there the needed parts to do this in place already, or are there still missing (e.g. in PulseAudio)? In the latter case, this bug should probably be moved, or a new one opened.

Lennart, ideas?

My guess is that the headset (or its driver) exposes missing or incorrect dB information. 

"amixer scontents -c0" might give a hint whether dB information is available.

The thing is, when I press (just one time) my volume key "up", the volume raise up by more than 30%...

How come it is now hard coded ? Wouldn't it be easier to just let a scale factor to be set by the end user ? 
Because, it would be almost impossible to find the right formula that works for every hardware...

What about step=min(your_formula(max_db); MAX_STEP_SIZE) where MAX_STEP_SIZE can be changed by the user ?


(In reply to comment #4)
> My guess is that the headset (or its driver) exposes missing or incorrect dB
> information. 
> 
> "amixer scontents -c0" might give a hint whether dB information is available.

(In reply to comment #1)
> This is probably the wrong way to do it. We currently show and change the
> volume based on 100%, and a certain number of steps. The size of the steps
> should be calculated from the maximum dB volume at 100%, so that a volume step
> feels like a constant increase in volume.

See Lennart's question in comment 4.

Bastien > here it is http://pastebin.com/raw.php?i=ujZBbrSA

(In reply to comment #7)
> Bastien > here it is http://pastebin.com/raw.php?i=ujZBbrSA

Attach it to bugzilla please.

Created attachment 191102 [details]
Output of amixer scontents -c0

Output of amixer scontents -c0

Created attachment 194416 [details]
Output of "amixer scontents -c0"

Change status as the info was attached

@The Green Arrow: You said that the scale jumps 30% when just pressing the button once... can I ask where you see this volume control? Is it what is listed in pavucontrol or gnome-volume-control UIs, or perhaps some underlying alsa kcontrol?

The fixed granularity of 6% is perhaps a little big generally but it shouldn't be crazy different volume wise. At quieter volumes this should amount to more than at higher volumes due to the cubic scale but even still we shouldn't see jumps of large percentages (large dBs I can imagine, especially when very quiet as -100dB to -60dB isn't actually that much different to my ears!)


Something else to try out is to switch ports to the headphone port. In an ideal world this would happen automatically but the underlying support isn't yet there (it's nearly ready!). So just use the Gnome UIs to change the "Connector" to headphones and see if that helps in any way to smooth things out.

Oh and if the 30% jump is still a problem, can you please do the following:

 amixer -c0; pacmd ls

both before and after the jump, and attach here?

Cheers.

*** Bug 658728 has been marked as a duplicate of this bug. ***

When I open alsamixer and turn my volume control wheel one notch after another, starting from 0% volume, I get the following steps:

9%
27%
46%
64%
82%
101%

I don't know why there are such large jumps. I first suspected that my volume wheel might produce multiple key events, but a quick test with "xev" shows that this doesn't seem to be the case. (The wheel also works perfectly under Windows 7.)

In addition, the headphone volume is already very high with 46%, and everything above 50% hurts my ears.

My bug 658728 got markd a duplicate of this but I don't really agree at all with this bug. My sound is working perfectly well with linear volume gain and drop and nothing is wrong about it.

My problem is that I have 18 steps from mute to max volume when using media keys on my keyboard or with my remote. I find that being too rough. Using the slider with the mouse gives me more control.

I just want the 18 steps to be changed to like 100 so you have more control when using the remote or keyboard to control volume. I understand this dB to linear conversion you speak of as I have done DirectSound programming before. That's nothing to do with my problem. Peace.

(In reply to comment #16)
> My bug 658728 got markd a duplicate of this but I don't really agree at all
> with this bug. My sound is working perfectly well with linear volume gain and
> drop and nothing is wrong about it.
> 
> My problem is that I have 18 steps from mute to max volume when using media
> keys on my keyboard or with my remote. I find that being too rough. Using the
> slider with the mouse gives me more control.
> 
> I just want the 18 steps to be changed to like 100 so you have more control
> when using the remote or keyboard to control volume. I understand this dB to
> linear conversion you speak of as I have done DirectSound programming before.
> That's nothing to do with my problem. Peace.

Yeah, not going to happen I'm afraid. If we make any changes, they'll likely be so that steps "feel" like they have the same loudness between them.

If you sitll want to change the number of steps yourself, plugins/media-keys/gsd-media-keys-manager.c and look for VOLUME_STEP.

Okay, nice with a straight answer at least. Are you also having 17-18 steps from mute to max? If so my report can be closed.

(In reply to comment #18)
> Okay, nice with a straight answer at least. Are you also having 17-18 steps
> from mute to max? If so my report can be closed.

Volume step is "6%" right now, so 16-17 steps right now. We might increase it slightly if it makes sense to snap with the underlying scales.

Then my sound is working absolutely perfect with no bugs. You have my thoughts about the step though.

I am having similar issues. On mine, however, I only get 10 steps.

From 100% >> 88 >> 74 >> 60 >> 48 >> 34 >> 21 >> 8 >> 0 >> Mute.

This is too sensitive for me. I have blasted my ears numerous times trying to dial in to a good sound, and the volume steps are noticeable through both headphones and laptop speakers.

*** Bug 663413 has been marked as a duplicate of this bug. ***

I also have problems with this.

My issue is that your ideal would work great if the sound card controls the whole chain such that the max db information is correct, which in many cases it might but in many cases it won't.

Say in my case for example where I use an external DAC connected through SPDIF and then to my speakers. How is my sound card supposed to know how loud the maximum volume is? Currently the maximum volume is hearing damage loud and I have at the moment 17 steps.

Step 2 is very quiet and step 4 is more than twice as loud. Even step 8 is louder than I'm comfortable listening to. All in all I have 6-7 usable volume steps steps from silence to max so fine adjustment is impossible.

It would be awesome if the steps were configurable, since as it is now is unusable in my system without resorting to ugly hacks and even then it works badly.

I really wish I was good enough to be able to fix this on my own, but I'm still working on that. In the meantime, all I can do is point out some of the work arounds a lot of people have tried on this link :)

https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/871133

My volume changes in steps of 32%, so I have only three steps to reach almost 100%, which is _very_ loud on my headphones. 1% steps is really nice (I currently use the custom shortcut hack described in the Ubuntu bugtracker linked in comment#24), but even if had the (former default, now hardcoded) 6% steps I would be happy. 32% is almost unusable... It worked fine with the 6% default in gnome2, btw.

I find this to be a serious regression from 2.x. It seems the entire GNOME team has decided that they know what the users want more than they do (I'm talking to you too, Nautilus team)
I want a configurable volume step value that doesn't involve me downloading the source, applying the Ubuntu patches, changing a #define that should be a setting in dconf anyways, and then continually running configure until I finally have all needed development packages. 

My 2¢.

Kevin: Patches welcome if it's so important for you that you even registered in GNOME Bugzilla to add your first comment. But absolutely no interest in your interpretations of "GNOME team" here, as it has nothing to do with this bug.

I just removed pulseaudio, installed volti, added it to session start-up and switched to "Gnome Classic". Voila, problem solved :-)

This is absolutely ridiculous.  This bug has been outstanding for more than a year and a half and the "fix" is both obvious and easy to implement.  All we want is a power user setting in gconf-editor which allows us to set the number of steps (which, btw, everyone in my circle of friends thinks is not granular enough).  Asking people to recompile to fix this is a bit excessive, no wonder gnome3 is tearing the community apart.

Still exists for me too :(  I know that there was talk about implementing this the right way, but has there been any progress or future direction for this issue?

Manfred: Your contributed patch is welcome, as it's so easy to implement. 
Thanks in advance.

I didn't realize we were being snarky.

Here is your patch.  Unfortunately, I can't release Copyright since I'm doing this from work.  But I'm confident you can come up with an even more flexible solution (hint, it was talked about above).

The following patch probably belongs to Google, Inc.  Talk to a lawyer there before incorporating it.

diff --git a/plugins/media-keys/gsd-media-keys-manager.c b/plugins/media-keys/gsd-media-keys-manager.c
index e5977d0..9b22c7a 100644
--- a/plugins/media-keys/gsd-media-keys-manager.c
+++ b/plugins/media-keys/gsd-media-keys-manager.c
@@ -95,7 +95,7 @@ static const gchar introspection_xml[] =
 #define TOUCHPAD_ENABLED_KEY "touchpad-enabled"
 #define HIGH_CONTRAST "HighContrast"
 
-#define VOLUME_STEP 6           /* percents for one volume button press */
+#define VOLUME_STEP 2           /* percents for one volume button press */
 #define MAX_VOLUME 65536.0
 
 #define GNOME_DESKTOP_INPUT_SOURCES_DIR "org.gnome.desktop.input-sources"

You can't have copyright on a number, seriously not even in the US. Also - this does nothing more than lowering the granularity which was my initial bug report a year ago. They told me they didn't want the volume step that small. It's design.

(In reply to comment #17)
> (In reply to comment #16)
> > My bug 658728 got markd a duplicate of this but I don't really agree at all
> > with this bug. My sound is working perfectly well with linear volume gain and
> > drop and nothing is wrong about it.
> > 
> > My problem is that I have 18 steps from mute to max volume when using media
> > keys on my keyboard or with my remote. I find that being too rough. Using the
> > slider with the mouse gives me more control.
> > 
> > I just want the 18 steps to be changed to like 100 so you have more control
> > when using the remote or keyboard to control volume. I understand this dB to
> > linear conversion you speak of as I have done DirectSound programming before.
> > That's nothing to do with my problem. Peace.
> 
> Yeah, not going to happen I'm afraid. If we make any changes, they'll likely be
> so that steps "feel" like they have the same loudness between them.
> 
> If you sitll want to change the number of steps yourself,
> plugins/media-keys/gsd-media-keys-manager.c and look for VOLUME_STEP.

(In reply to comment #19)
> (In reply to comment #18)
> > Okay, nice with a straight answer at least. Are you also having 17-18 steps
> > from mute to max? If so my report can be closed.
> 
> Volume step is "6%" right now, so 16-17 steps right now. We might increase it
> slightly if it makes sense to snap with the underlying scales.

"We might increase it slightly" -> I vote we do, I still feel 6% is a too large volume step and obviously a lot of people agree.

I hit this problem just today, when I connected a powerful speaker system to my laptop. I am not able to enjoy my music collection as I am not able to quickly adjust the volume with keyboard shortcuts.

Are we only waiting for a patch? If so, I am willing to invest the time in contributing a patch. I am an experienced programmer in general, but have no familiarity with gnome code base.

Before I spend time in digging into the code, could someone with commit rights please confirm that a suitable patch which restores dconf flag for volume step size be merged in? That is, is it acceptable at a design level?

Thanks,
HRJet

Allow me to add another anecdote,

I've got a very powerful stereo power amplifier and some very large floorstanding speakers that I usually hook up to my computer using a preamplifier. However after some recent system changes I no longer have a cable that can connect the pre to the poweramplifier.

So I plugged in a USB DAC that I had handly, turned the system volume all the way down, the power amplifier on and played some music. I then used the media keys to adjust the volume up one notch and nearly had a heart attack due to the extreme volume. Thankfuly the poweramplifiers protection cuircuitry kicked in and prevented any damage.

Basically, everyone's system is different, there's no way 6% or 3% adjustment will cover everyones needs. Now that I've adjusted the volumes correctly, the difference between the last two steps of volume is 93dB and 115dB, which is not at all subtle.

It still wouldn't have saved my ears, however.

Crazy to think that a bug causing a genuine safety hazard doesn't get much attention. What needs to happen to get code implemented properly? Can we get some more direction from dev's on how to write something that will solve this problem?

System settings -> Sound could add a slider "Volme adjustment step" or similar. There is already an output volume slider so adding another one could be a solution.

*** Bug 691693 has been marked as a duplicate of this bug. ***

Most of the time I listen to music while working on my laptop, and I also would like to have a finer control on the volume steps.

But on the other hand, if for some reason I push the volume to max, I want a quick way to get back to a normal volume level when I plug my headphone.

So, looking for a simple solution, I learned that on MacOs they use a key modifier that allow you to switch between normal steps or fine grained one.

Using the Shift or Alt modifiers + mouse wheel or keyboard volumes keys should do the trick. 

Is this something that could be integrated if a patch is provided ?
(did not had a look at the code currently but I can do it if it match the design )

Almost two and a half years later, and this still hasn't been addressed.  I've introduced over a dozen people to Ubuntu over that time, and all of them agree that these 6% volume steps are way too large.  I am constantly opening graphical volume sliders to try to get the volume right, and it is extremely annoying.  The anecdotes above indicate that, for some hardware configurations, steps this large may even create a safety hazard.

Addressing this problem be re-adding a Volume_Step dconf entry sounds like a very reasonable solution and an extremely trivial fix, but I am not a software developer.  Please consider making Volume_Step configurable by some method other than downloading, editing, and recompiling the source, as that is beyond the ability level that may be assumed for the great majority of users.

Created attachment 264171 [details] [review]
Make volume step a setting

Please, excuse the spam, but let me sum things up first.

Some people claimed there are setups where the maximum volume setting of 100% is not save-for-your-apartment-neither-ears. I've heard several AV receivers in my life and I can absolutely confirm that this is not a lie.

I'm getting the impression that the person who thought 100% is a save maximum in every environment and so 6% have to be a good choice for everyone as well had probably a laptop and its speakers or a mobile device in mind.

For users with better speakers 6% can be really inconvenient, because between two steps one might be too low and the other one too loud – I e.g. noticed myself using the UI slider a lot instead which is sad.


So, say I had such an "easy" patch for configurable volume steps at hand (which I happen to do) and had written it at home, far away from Google, any lawyers or copyright, who would I have to talk to, to get it rejected? ;)


(attached patch applies against 3.10.2 and master as of today)

Comment on attachment 264171 [details] [review]
Make volume step a setting

As per discussion earlier in the bug. I'm not making this configurable. Please find a way to use dB information from the sound card to provide a decent default. Swapping a hard-coded number for another one isn't going to fix it, and neither is a hidden configuration option.

Bastien, how do you address the following use cases that were raised in previous comments:

Comment 36:

"I've got a very powerful stereo power amplifier and some very large
floorstanding speakers that I usually hook up to my computer using a
preamplifier. However after some recent system changes I no longer have a cable
that can connect the pre to the poweramplifier.

So I plugged in a USB DAC that I had handly, turned the system volume all the
way down, the power amplifier on and played some music. I then used the media
keys to adjust the volume up one notch and nearly had a heart attack due to the
extreme volume. Thankfuly the poweramplifiers protection cuircuitry kicked in
and prevented any damage."

Comment 23:

"My issue is that your ideal would work great if the sound card controls the
whole chain such that the max db information is correct, which in many cases it
might but in many cases it won't.

Say in my case for example where I use an external DAC connected through SPDIF
and then to my speakers. How is my sound card supposed to know how loud the
maximum volume is?"

(In reply to comment #44)
> Bastien, how do you address the following use cases that were raised in
> previous comments:

We still can have good defaults, based on dB information *and* on the connectors used. In any case, adding a "fix it yourself" option isn't what we want to implement. If somebody wants to have a go at fixing this properly, I'll gladly review, but adding a "figure it out" knob as in the patch from comment 42 (and the ones in the duplicate bugs) isn't going to get accepted.

Since we seem to be going in circles, let me give an analogy.

Bug report: The `ls` command is not giving enough information about files. Would be nice to have an `-l` option. It used to work great in version 1 of `ls` but seems to have disappeared in version 2.

Response: There's no need for `-l` option. Let's not bother the user with all these settings. It is better if ls can figure out the terminal width automatically and choose the right amount of detail to present.

Comment: But my terminal doesn't report its width, and sometimes it reports is wrongly. Moreover, sometimes I need file details even if my terminal width isn't big enough as deemed by `ls`.

Response: If you want to fix this properly, send a patch. Adding a "figure it out" knob is not going to be accepted.

Registering a Bugzilla account just to mistakenly calling "not giving enough information" an "analogy" here and comparing well-defined terminal command parameters to the behavior of a UI slider likely doesn't help anybody.

Another long-time user/advocate and first-time commenter here.  Feel free to denigrate and minimize my contribution to the discussion too, as I only registered a Bugzilla account to comment here.  (Maybe it's a sign that people are doing that?)

The annoyance that this bug causes on my hardware is much less troubling than the level of 'we know best' design arrogance expressed in this thread.

I left Windows precisely because the developers decided that they knew better than I did how my software should work.

Having a vision that informs how the defaults are set is one thing; making design decisions that arbitrarily restrict a power user's ability to adjust those defaults is another thing entirely.  dconf is there for a reason.

I'd be in favour of having a key that you press to get fine grain control over the volume, with the option to invert the behaviour so that users wanting fine grain control all the time can get it.

But also, anyone who finds the volume overall excessive should take care to get the information Lennart suggested and then make a bug upstream (not sure which project PulseAudio? ALSA?).

Correct me if I'm wrong on that.

As already proved by counter examples, such as connected amplifiers: you can't get reliable dB information because the sound card is not controlling the whole audio chain.

Everyone in this thread either wants the 6% step to be configurable (which is already implemented in a, stubbornly rejected, patch) or just lowered to something smaller.

16 steps is not a good default, and having that value hardcoded as a C macro in some source file that you need to recompile to change is not as good as the proposed path from comment 42. Stubbornly rejecting an improvement because it's not the perfect-golden-auto-dB-fix-everything is not the way to go. Even having it a hidden configuration is better because then distributions can choose what values to use without having to fork stuff. Trying to compile anything GNOME is a nightmare. I tried compiling the shell for like 2 weeks with little success. Changing a configuration is much easier.

Microsoft Windows - like it, hate it, come with 100 steps from 0 to 100%. I don't see the problem in lowering the default step size. If you have a remote control and you hit volume up and you don't hear any difference what do you do? Answer: you hit it again. It doesn't work the other way around. If one step is too low and the next is too high you ruin the whole point of having a remote control.

Btw - after reading the whole thread I see I didn't get the *hilarious* joke at comment 32 - I feel retarded. Comment 32 and comment 42 are the two possible solutions to this bug report (if you aren't aiming for the golden-auto-db-impossibility). But hey - I'm just a regular 4 year solid GNOME-as-my-only-OS-user so why listen to me?

Please accept the change restoring configurability from comment 42.

Even if one were to accept the premise that the perfect answer would be querying this information from the sound card, perfect is the enemy of good.

Three years waiting for perfect hasn't worked.

Take good.

"Perfect is the enemy of good" - what a brilliant quote! Trying to achieve the perfect solution, yet end up with... nothing at all.

Just another user bothered enough about this to read this whole thread and register just to check-in here. 

What would it take for this to get fixed? I'm genuinely curious about why this bug which seems like a simple thing has been open for three years. Is there something I, as a user, could do to help? Is there a limitation on a third-party software?

I can't understand what kind of challenge it must be to solve this if you guys were able to build this huge piece of software that we use every day and now you can't change this tiny part of it's behaviour.

Cabanur, I'm afraid there isn't anything you can do. There's a lot hardware and configurations that cannot report back actual volume. The only suggested solutions that are at all reliable have been rejected by the developers.

LibreGNOME anyone? Eh, eh?

Hi, some response to comment 53? 

This behaviour of Gnome really is inconvenient. It would help a lot to be able to configure the volume step size. That is at least until the the perfect solution that is able to extract dB information from any hardware is possible.

I've registered specifically to comment on this issue as well. But I have some good news for Ubuntu and Ubuntu Gnome users. I applied Alex Hofbauer's patch to both gnome-settings-daemon and unity-settings-daemon and uploaded them to a PPA: https://launchpad.net/~george-edison55/+archive/ubuntu/gnome-settings-daemon

To add the PPA and upgrade:

    sudo apt-add-repository ppa:george-edison55/gnome-settings-daemon
    sudo apt-get update
    sudo apt-get upgrade

After restarting, the volume increment can be changed by editing the "org.gnome.settings-daemon.plugins.sound.volume-step" dconf value:

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

Feedback is welcome and appreciated.

I would really like to see Alex Hofbauer's patch applied upstream (i.e. here...), too.
I follow this bug ever since I got my notebook about a year ago - still hoping this might eventually be fixed even though the odds are low.

If I connect the headphone to my laptop the Vol+/Vol- keys are useless. I always have to use the mouse/touchpad to set the volume.
Using the Vol+/Vol- keys the range from muted to painfully loud are ~5 steps...
I agree that the perfect solution would be to extract the dB information from the hardware, but it in case this does not work (like for most people here and probably many more) and cannot be fixed within a day.
For this case a workaround within GNOME would be really helpful.

I like GNOME, but this one thing really, really annoys me and I do not understand why the developers are so rigid about this.
I don't need a nice gui to configure it. A hidden setting with dconf in case the default does not work properly is all I (and probably most other users here) ask for.
I would highly appreciate if the developers reconsidered applying the patch.

It might be worthwhile noting that PulseAudio has a potential workaround.

In default.conf there is a section [DecibelFix]

[DecibelFix element]

Decibel fixes can be used to work around missing or incorrect dB
information from alsa. A decibel fix is a table that maps volume steps
to decibel values for one volume element. The "element" part in the
section title is the name of the volume element.

NOTE: This feature is meant just as a help for figuring out the correct
decibel values. PulseAudio is not the correct place to maintain the
decibel mappings!

If you need this feature, then you should make sure that when you have
the correct values figured out, the alsa driver developers get informed
too, so that they can fix the driver.

; db-values = ... 

The option value consists of pairs of step numbers and decibel values.
The pairs are separated with whitespace, and steps are separated from
the corresponding decibel values with a colon. The values must be in an
increasing order. Here's an example of a valid string:

"0:-40.50  1:-38.70  3:-33.00  11:0"

The lowest step imposes a lower limit for hardware volume and the
highest step correspondingly imposes a higher limit. That means that
that the mixer will never be set outside those values - the rest of the
volume scale is done using software volume.

As can be seen in the example, you don't need to specify a dB value for
each step. The dB values for skipped steps will be linearly interpolated
using the nearest steps that are given.

Taken straight from:

https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/profile-sets/default.conf

Hopefully this will help folks out. And protect their hearing.

In additional to the last comment, David Henningsson developed a tool to make working out incorrect decibel information.

I even made it print out the necessary values to copy/paste although when I went looking for it, I see it was in a private branch and I don't think David ever merged it back... strange. I must have forgotten to ask him about it.

No idea now if the code I wrote actually works or is valid, but it's probably worth a shot :)

http://colin.guthr.ie/git/audio/alsamixertest/log/?h=colin

David, if you see this perhaps you could take a look at my (now very old!) patches and see if you want them for an updated release :D

Ah...finally I found a bug to file (and patch) for unity-settings-daemon!! @Alex Well done.

But seriously, why do you all want vanilla Gnome so much? Gnome gives us only the base platform. Others are there to expand it. Let upstream do the hard work. "Others" will fix it with patches. Sweet, cute little patches. So ask those "others". Make it happen in Debian. Then you can have it in Ubuntu. Don't like Unity? Use Ubuntu-Gnome. Enjoy blissful music. Cheers.:)

I just want to be able to use the cool roller on my corsair K95. Unfortunately the step are too big. Whatever I want is almost always between two steps and I have to run pavucontrol to get what I want. Just let me change step size. That there is no way to get every possible setting of volume is wrong. Why would you decide for me which ones I'm alowed and which I am not? I hate Windows, but have to use it for a class right now (for Adobe products), and they let me get all of the volume settings. Why don't you? That's user hostile.

This is the only thing that I find pretty annoying on Gnome 3 right now. On my laptop I have dedicated buttons for volume control. On Windows 10 they give me an excellent 2% step, while on Gnome its 6%, and the perfect volume is always between those 6% steps. I just can't understand why there's no option for this anymore. The explanations that were given by the staff just doesn't make any sense.

(In reply to Alex Hofbauer from comment #42)
> Created attachment 264171 [details] [review] [review]
> Make volume step a setting
> 
> (attached patch applies against 3.10.2 and master as of today)

Alex or anyone else, please adapt the patch to the latest changes of gnome-setting-daemon 3.24.

(In reply to Maxim from comment #64)
> (In reply to Alex Hofbauer from comment #42)
> > Created attachment 264171 [details] [review] [review] [review]
> > Make volume step a setting
> > 
> > (attached patch applies against 3.10.2 and master as of today)
> 
> Alex or anyone else, please adapt the patch to the latest changes of
> gnome-setting-daemon 3.24.

Just a reminder that I have a PPA (for Ubuntu users) with the patch applied to all current versions of gnome-settings-daemon in the archives:

    https://launchpad.net/~george-edison55/+archive/ubuntu/gnome-settings-daemon

Feel free to copy the patch out and adapt it to your needs.

(In reply to Maxim from comment #64)
> (In reply to Alex Hofbauer from comment #42)
> > Created attachment 264171 [details] [review] [review] [review]
> > Make volume step a setting
> > 
> > (attached patch applies against 3.10.2 and master as of today)
> 
> Alex or anyone else, please adapt the patch to the latest changes of
> gnome-setting-daemon 3.24.

Here you go, this patch works against gnome-settings-daemon 3.24.1:

https://aur.archlinux.org/cgit/aur.git/plain/volume-step.patch?h=gnome-settings-daemon-volume-step-patch&id=18494a53983173a96c2719daab6d1dd94694f8b7

For anyone using Arch Linux, I maintain an AUR package with the patch applied here: https://aur.archlinux.org/packages/gnome-settings-daemon-volume-step-patch/

Actually the better solution would be to be able to set the number of steps.

This way we do not say anything about the real dB step values, this can be guessed/calculated/read from some lower level software/hardware.

As a sidenote: The current way is really not perfect.
It is mostly OK on my notebook but it's really bad on my desktop machine.
Neither proposed solution here is perfect, but any one of them is better than the current one.

@André Klapper: the mere fact that someone makes through the registration hassle just to write a comment to a bug report indicates the frustration the given user had. And the more users feel like this the more severe the issue is. These are the second most important users from a project perspective (right after those users who know how to contribute with code).

Does anything speaks against making the number of steps configurable?
It's really annoying not being able to fine adjust the volume, especially when listening to music.

Created attachment 355571 [details] [review]
media-keys: Change order of key to match shortcuts list

Created attachment 355572 [details] [review]
media-keys: Switch boolean do_sound_action() args to flags

Much cleaner, and more easily extensible.

Created attachment 355573 [details] [review]
media-keys: Add a precise volume change shortcut

3 precise presses = 1 non-precise press

Review of attachment 355571 [details] [review]:

++

Review of attachment 355572 [details] [review]:

looks good

Review of attachment 355573 [details] [review]:

right, I think this is a neat solution

Attachment 355571 [details] pushed as 2261977 - media-keys: Change order of key to match shortcuts list
Attachment 355572 [details] pushed as 0469ff8 - media-keys: Switch boolean do_sound_action() args to flags
Attachment 355573 [details] pushed as e1179ad - media-keys: Add a precise volume change shortcut

Hi Rui, could you please describe what just happened here? If I read the patches right, you added Shift+VolumeUp/VolumeDown shortcut, which changes the volume by 2%, instead of the default 6%. That is awesome, thanks a lot for that! (Even though I'd still prefer the have the same functionality without holding down Shift; but still great). Are the volume steps configurable, though? (Which this bug seems to be about, e.g. in gsettings). I don't see that in the patches.

Also, will the new shortcuts appear in gnome-control-center?

Thanks for explanation.

@Rui Matos

Is north pole becoming south pole? Shouldn't it be 

    Volume_Step 2
    Volume_Step_Precise 6
 ?

This is better, but not what was requested. 

"Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...

Marty DiBergi: Oh, I see. And most amps go up to ten?

Nigel Tufnel: Exactly.

Marty DiBergi: Does that mean it's louder? Is it any louder?

Nigel Tufnel: Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from there? Where?

Marty DiBergi: I don't know.

Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?

Marty DiBergi: Put it up to eleven.

Nigel Tufnel: Eleven. Exactly. One louder.

Marty DiBergi: Why don't you just make ten louder and make ten be the top number and make that a little louder?

Nigel Tufnel: [pause] These go to eleven."

Unbelievable that after many years this remains a hardcoded value in the C code. This thread is getting bookmarked. After numerous users keep requesting the ability to be able to configure the volume step size like other DEs offer, and after some even wrote the code and requested it be merged, the GNOME team shuts it down over and over again. 

Yet another in a long list of examples of some GNOME developers being not just indifferent, but openly hostile to what users explicitly say they want.

No one is arguing against having sane defaults. Note how no one complained about the default being 6%. People requested a new preference option (or unremoval of a previous one) which started out with a level of frustration about the repeated removals of user preference settings, but understandably this transitioned into deeper frustration with GNOME devs' outright refusal to allow for those options even when presented with them and when it is made clear that users want the ability to change the value from the default.

The precise Shift+VolumeUp/Down is a bare-minimum concession to the userbase but is not a fix to the issue.