After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 657607 - Don't make max volume go up to 11
Don't make max volume go up to 11
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-08-29 11:35 UTC by Bastien Nocera
Modified: 2011-09-05 12:19 UTC
See Also:
GNOME target: ---
GNOME version: 3.1/3.2


Attachments
Revert "volume: Increase maximum by 50% for outputs with decibel support" (4.25 KB, patch)
2011-08-31 10:50 UTC, Bastien Nocera
committed Details | Review

Description Bastien Nocera 2011-08-29 11:35:50 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=649411 for details, but this basically means reverting:

commit bdd805a3eea2a4bf88bb77e5ad7da50b0bd9fdd5
Author: Adel Gadllah <adel.gadllah@gmail.com>
Date:   Wed Feb 9 21:18:20 2011 +0100

    volume: Increase maximum by 50% for outputs with decibel support
    
    Volume should go up to 150% if the sound card used as output has
    decibel volume support.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=641886
Comment 1 Bastien Nocera 2011-08-31 10:50:54 UTC
Created attachment 195285 [details] [review]
Revert "volume: Increase maximum by 50% for outputs with decibel support"

This reverts commit bdd805a3eea2a4bf88bb77e5ad7da50b0bd9fdd5.

Conflicts:

	js/ui/status/volume.js
Comment 2 Bastien Nocera 2011-08-31 10:52:09 UTC
Note, untested. This needs to go in 3.2.
Comment 3 drago01 2011-09-03 11:18:33 UTC
Review of attachment 195285 [details] [review]:

Looks good.
Comment 4 Milan Bouchet-Valat 2011-09-03 13:04:14 UTC
What does this mean in terms of UI? The volume slider and keys will only allow going until 100%, and we'll need to go to sound preferences to go above?

I agree going beyond 100% without notice has drawbacks, but on several computers I saw, amplification was so weak that users needed to go to 150% in several occasions. Can't we find a way to allow going to 150% while making it clear sound might not be optimal? Maybe by coloring the slider beyond 100%, or by showing a tick mark?

Generally, the fact that we allow going to 150% in the sound preferences is the sign that this can be useful. If it is, I think the volume indicator should be more or less consistent with it.
Comment 5 Florian Müllner 2011-09-03 13:09:44 UTC
(In reply to comment #4)
> What does this mean in terms of UI? The volume slider and keys will only allow
> going until 100%, and we'll need to go to sound preferences to go above?

Yes.


> Generally, the fact that we allow going to 150% in the sound preferences is the
> sign that this can be useful. If it is, I think the volume indicator should be
> more or less consistent with it.

Maybe a use case for another <alt>ernative?
Comment 6 Milan Bouchet-Valat 2011-09-03 14:51:22 UTC
(In reply to comment #5)
> Maybe a use case for another <alt>ernative?
Maybe.

Or when people use mouse scrolling or volume keys, allow them to go past 100% if they continue scrolling/hitting keys (which probably means they consider the current volume isn't enough for them). The important part is that there's a visual feedback that they are asking the OS to go beyond normal sound amplification.

Let's hear what designers think about this.
Comment 7 Bastien Nocera 2011-09-05 10:50:36 UTC
Pushed. Please create a separate bug if you want the functionality
re-added. It's already been discussed that the default implementation
shouldn't allow for > 100% volumes in bug 649411 (by both sound
people at the Desktop Summit, and designers).

Attachment 195285 [details] pushed as d99a2f1 - Revert "volume: Increase maximum by 50% for outputs with decibel support"
Comment 8 Milan Bouchet-Valat 2011-09-05 12:19:18 UTC
Fair enough. I've filed bug 658248.