Bug 523809

The slider match the application volumes. You're asking for changes in the way flat-volumes work.

The behaviour of the application sliders wrtt to the global slider is very counterintuitive, especially the way they control each other and attach/detach.

I would expect the global volume slider to change all of the volumes proportionately, rather than affecting relative volumes like it does. Similarly I wouldn't expect increasing an application slider to then prevent the global volume from controlling all the other apps.

I think the best model to follow here is a mixing desk. They're very intuitive and easy to understand, even for people who've not used one before, and many years of use have demonstrated that the concept works well.

Kamil's suggestion of app sliders being a percentage (or dB) would seem to be much more usable and how I would have expected this to work. One improvement software could make over a passive mixing desk would be to allow amplification on a stream so that you could control from say 0 to 150% (or say -40dB to +20dB). This would easily allow you to make a stream louder if it was a little too quiet without having to adjust all the other streams quieter instead.

(In reply to comment #0)
> Description of problem:
> Every time I use application volume sliders (Applications tab) it causes me a
> little pain. I am a developer and I still don't understand how exactly the
> sliders work. I don't like to use it. And that's a bad sign. I believe it was
> created to "behave intelligently" but maybe simpler would be better.
> 
> What I don't like:
> 1. When I want to have totem louder than everything, I just pull the slider up
> (in totem or in g-v-c). But that increases global volume and unbind other
> applications, so after closing totem and putting global volume to 100%, I can
> have other applications still at only 50% (much quieter than before). How can a
> noob user then find out why all the apps are so quiet even when he has global
> volume on max? On the other hand, when some new app starts during my totem
> playback and beeps, it's the same volume as totem (bcz the global volume was
> increased). Loud beeping hurts.
> See https://bugzilla.redhat.com/show_bug.cgi?id=523776

The sink volume acts both a "upper limit" of the volume of all stream volumes and as reference volume of stored volumes.

I am not sure I understand your point though.

> 2. When I lower volume for some application, it's very hard to put it back to
> sync with the global volume.
> See https://bugzilla.redhat.com/show_bug.cgi?id=523802

This is a valid point. We should find a way to simplify this. I think it would be good if g-v-c would show a "magnetic" marker on the stream sliders that show where the sink volume is at.

> 3. Sliders moving other sliders are very counter-intuitive. Especially when
> that happens only sometimes (moving application volume down does not change
> global slider, moving up does; increasing global volume increases app volume,
> but increasing global volume through one app volume does not change other apps
> volumes; etc). Gives me a headache.

I am sorry, but I simply disagree. The fact that we were able to merge the many sliders we had in a series into a single slider is a big simplification. When the stream and sink sliders where independant it was much harder to figure out which slider is the reason your sound was too faint. With the new logic in place each app has its own volume slider and when you move that up it is guaranteed to actually control the final volume in its full range and granularity.

> What about changing the current state, when app sliders relate to the real
> volume (dB), to percentage-based approach, where app sliders relate to the
> percentage of the global volume? Example: If I have totem at 50%, it always
> plays at half of the global volume. Therefore if I move global slider, it
> doesn't change totem slider (it's still 50%). That could be much more
> intuitive. It could look like the Input tab, where there is a line saying
> "100%" and you just know how it works.

We used to have that. And you can still enable this behaviour by setting flat-volumes=no in daemon.conf. However, I think this is really counter intuitive because it is really hard to figure out which slider is to blame when sound is to faint (among other sinks).

I am quite sure that your criticism is mostly based on the fact that it is different what we used to do. However, the new logic is more intuitive I believe especially for new users. Also, it's what Vista does, so this logic should be known well for people joining us from the windows camp:

http://www.patrickbaudisch.com/projects/flatvolumecontrol/index.html

Every approach you pick has advantages and disadvantages. I do believe that the new flat vol logic is the best solution we had so far, by a wide margin. 

The point you raised in 2. is valid and we should improve this.

(In reply to comment #2)
> The behaviour of the application sliders wrtt to the global slider is very
> counterintuitive, especially the way they control each other and attach/detach.
> 
> I would expect the global volume slider to change all of the volumes
> proportionately, rather than affecting relative volumes like it does. 

Uh? That's exactly what happens. If you change the device slider the volumes of all streams are changed proportionally so that their relation to each other stays constant.

> Similarly
> I wouldn't expect increasing an application slider to then prevent the global
> volume from controlling all the other apps.

Uh? This is exactly what happens: if you change the stream slider this will only change the stream slider and possibly 'push' the device slider. It will leave the volumes of the other streams untouched. If you change the sink slider however the volume of all streams will be adjusted exactly the same way.

> I think the best model to follow here is a mixing desk. They're very intuitive
> and easy to understand, even for people who've not used one before, and many
> years of use have demonstrated that the concept works well.

There are different mixing desks. And stuff that might be good for prop audio might not be good for desktop audio.

> Kamil's suggestion of app sliders being a percentage (or dB) would seem to be
> much more usable and how I would have expected this to work. One improvement
> software could make over a passive mixing desk would be to allow amplification
> on a stream so that you could control from say 0 to 150% (or say -40dB to
> +20dB). This would easily allow you to make a stream louder if it was a little
> too quiet without having to adjust all the other streams quieter instead.  

Uh? This makes no sense at all. In PA 0.9.17 you can simply move the volume slider of the stream you want to make louder and it will get louder and all other streams keep the same volume. Not sure what you are talking about.

(In reply to comment #4)
> Not sure what you are talking about.  

Sorry, I've spent a while playing with it and it makes more sense now please ignore comment #2. I think the new behaviour is reasonable.

I note though that the alert volume in the sound effects tab doesn't seem to follow the model of the applications sliders at all. Bit confusing having that behave differently.

(In reply to comment #5)

> I note though that the alert volume in the sound effects tab doesn't seem to
> follow the model of the applications sliders at all. Bit confusing having that
> behave differently.  

That is a valid point. This should be fixed. Unfortunately this requires extensions to the protocol, so won't happen that quickly.

I have played with the flash demo a little:
http://www.patrickbaudisch.com/projects/flatvolumecontrol/index.html
and the thumbwheel seems to me much more intuitive than the master slider :) But I admit, it just might be a problem of getting used to a different paradigm. If all the little problems are solved (like the bug #523802), all the little pains are gone, then it might be quite a nice way to control volumes.

Sorry, I had a little trauma from all the minor bugs when reporting this, let's just close it.

I agree that the thumbwheel makes the interface a lot more intuitive (although their graphic is quite ugly).

I think the reason for this is twofold:

1. Changing the app sliders doesn't move the thumbwheel

2. The thumbwheel doesn't have end stops so will turn as far as necessary, thus it is a true relative control without an absolute position.

(1) is a consequence of (2) and makes the behaviour much easier to understand.

Martin, you have captured it quite nice. My hi-fi set at home has a round button which can be turned clockwise or counterclockwise without any limits (there are no "stop" positions, you can turn it endlessly). Of course there are internal limits on the volume, but this kind of interface frees you of thinking about enforced limits and enables you only to concentrate on the desired volume level.

If the global volume is implemented differently from a classic slider, it means the user has one slider less to think about. It may be worth considering.