[pulseaudio-discuss] Stream volumes as the universal volume adjustment method

[Tanu Kaskinen]

su, 2010-01-10 kello 08:01 +0200, Tanu Kaskinen kirjoitti:
> Forwarding my reply to Mads to the list also.

Ok, this is great - the forwarded content didn't seem to get through.
I'll just copy-paste the message then:


su, 2010-01-10 kello 00:57 +0100, Mads Kiilerich kirjoitti:
> Tanu Kaskinen wrote, On 01/08/2010 05:32 AM:
> > pe, 2010-01-08 kello 01:02 +0100, Mads Kiilerich kirjoitti:
> >> My solution is to ignore the stream volumes and always change the device
> >> volume.
> >>      
> > So you want the volume widgets in various apps to disappear or make them
> > change the device volume?
> >    
> 
> I haven't thought a lot about that. But I know for sure that I want a 
> central place where I can control the volume of all active (and future) 
> streams, both all of them together and individually/relative to each 
> other. I expect that volume controller to be easily available on the 
> screen, and also that the volume keys by default control the volume of 
> everything at once.

Me too, if "everything at once" means all currently playing sounds. I
don't want the volume keys to change what has previously been set to a
correct value. But apparently you see this differently, which is
understandable if in most cases for you volume changing happens because
of listening context changes.

> > Or maybe you want us to keep on doing what we do now, where you should
> > not touch the per-application volume controls when doing listening
> > context related changes. Ordinary users don't know this rule. Even if
> > you know this rule, with each volume change you have to think whether
> > this it should be done to stream or device volume so that you can choose
> > the right volume widget to tweak. I would rather just have a reflex of
> > turning my volume dial whenever I notice the volume isn't right.
> >    
> 
> I also just want to "adjust volume" when the volume isn't right. But 
> FWIW I do think the best way to do that is to control the "master" 
> volume. If I notice that I keep adjusting the volume when I switch 
> between background music and game sound then I can either keep adjusting 
> the volume every time or adjust their relative volume. And similarly, if 
> I find the event sounds too loud compared to my background music then I 
> have to adjust their relative volume. I don't think there is any special 
> rule users will have to know. Both the volume keys and the notification 
> area volume control does what should be used most of the time. But of 
> course, if the applications puts a volume control in a prominent place 
> and it does the wrong thing, then the user would have to learn not to 
> use it.
> 
> (But of course I don't "want" you to do anything you don't like. I just 
> noticed something which seemed like a step backward, so I spoke up and 
> said what I thought I wanted. I have learned something - thank you - and 
> I hope you can use my input too.)

I used the word "want", because we are discussing what should be the
default behavior, and surely you want the default be something different
than what I want :)

And yes, your feedback is very useful. I have realized that tying the
hardware volume controls to the master volume actually works as well as
tying it to the stream volume, assuming that the streams volumes are set
correctly relative to each other. Using the master volume also works
better with listening context changes.

So it seems that what is up to debate is just the question of which is
worse:

- With device-centric volume you have to change the volume needlessly
often if your applications don't have the right volume relative to each
other. For that reason you should also know not to touch the
application's own volume slider, unless you specifically want to tune
the relative volume (which should be done just once).

- With stream-centric volume you have to change the volume needlessly
often when you change listening contexts.

So device-centric volume works pretty much perfectly if you know enough
about how volume controlling works with pulseaudio (which I believe is
not the case for most users), and stream-centric volume works pretty
much perfectly if you don't change listening contexts (which I believe
is not the case for anyone who uses a laptop not only as a desktop
replacement, but who actually moves it around).

I think the group that fulfills the necessary condition for the
device-centric scheme is smaller than the group that fulfills the
necessary condition for the stream-centric scheme. On the other hand,
ignorant users have always had difficult life, but laptop users have
always been somewhat happy with the current system, so they would
complain very loudly about any new inconveniences.

I happen to fulfill both of those conditions, so I should be - and
indeed I am - happy with either scheme. Since even I am not sure anymore
which is a better default for everyone, I will drop my plans to
implement the stream-centric scheme. As I've said, the UI improvements
still make sense to me, and module-dwim would still make life easier for
programs handling the hardware volume control events. But I don't think
I have the motivation for those things either anymore.

As an off-topic note, I realize now that the per-stream port volume that
I proposed earlier isn't needed with the device-centric scheme, where
the stream volumes are changed *only* to fix the relative volume between
applications. This assumes that with each output the relative volume
should be the same, though, but this might very well be a valid
assumption.

> >> So if I adjust the volume with one application playing and then start
> >> another application then the other application will use its default
> >> volume and the relative volume will thus have changed?
> >>      
> > Yes. This is the problem problem with my approach, which I argue is
> > smaller than the current problems and the problems with the
> > device-volume-only approach. You can form a reflex so that whenever the
> > volume is wrong, you know what to do without thinking so the problem is
> > not so big. Although, I admit that for users who
> >
> > * use desktop event sounds,
> > * change the listening context frequently
> > * and most of the time have music or other "real" stream active,
> >
> > this is still quite bad, since the music volume and the event sound
> > volume has to be changed individually and you have to go through
> > clicking the volume applet. For those users I don't have other solutions
> > than just dropping one of those three habits or living with the problem.
> >    
> 
> FWIW:
> 
> I don't get it. Here you agree that there is a problem with what seems 
> to me to be the most common usecase. What is the problem you are trying 
> to solve, and in what way do your proposal solve it? I guess I need the 
> "I hope you understand without further explanation" explanation.
> 
> Why do you want to change the stream volume so often, and why can't the 
> master volume be used?

I need to change the stream volume so often, because not every song and
every video has the same volume. Correcting for a quiet song is
obviously a stream-specific change, but - as I realized today - the
master volume works just as well in practice.

> In what way and why and how do PA lose track?

For refreshing the readers' memory, this refers to the situation where
the user uses sometimes the stream and sometimes the device volume to
correct for wrong volume. This can happen easily: the user may use the
hardware controls that tweak the device volume, or the user may have
just music playing and notes that the volume is too low, and then
adjusts the music player's own volume widget that controls the stream
volume.

Here's nothing new for you, since you already acknowledged that the
volume sliders in various applications shouldn't generally be used in
the current model. So I guess you actually understand the problem
without further explanation :)

-- 
Tanu Kaskinen