On Mon, 25.05.09 12:51, Jud Craft (craft...@gmail.com) wrote: > I understand how audacious it would be to post and tell you that > Pulseaudio is doing the volume scaling wrong, but let me demonstrate a > problem. I won't post twice -- I know you guys are busy on this list > -- but I've really wanted to mention this. I've seen Redhat Bugzilla > #494112, but it seems to glance over the problem. > > I know that Pulse can remember the volume of an app. And when Pulse > also scales the main-system volume (with only one program, App A, > present), it remember that app's volume, say 75%, and sets the main > system volume to it. All is good. Set App A to 75%, and Pulse sets > the system volume to 75%. > > But what happens when you run another program (App B), that has a > per-app volume of 80%? It appears that Pulse remembers the volume of > App B too. > > In this case, it appears that Pulse rescales both apps, so that the > main system volume matches App B (80%), and App A is set so that it > has a relative volume to App B. (ie, if App A has only 75% of the > main system volume, and 80% is the main volume, so App A now has .80 x > .75 = 60% volume).
Uh? No, that's wrong. First of all, using percentages for this is misleading. The percentage scale is artificial and has only an indirect connection to what happens internally. It is explicitly *not* a factor that is used for actual volume adjustments. If you have one stream A at linear volume factor X and one B at linear volume factor Y with X < Y, then the device will be configured to Y and internally the data from B will be passed through untouched and the one from A will be attenuated with the factor (X/Y). That is completely different from what you wrote above. > This maintains the correct per-app ratio (App B is louder than App A), > but it changes the main system volume. In addition, if a program that > has no per-app volume yet (with a default of 100%) is launched, then > Pulse resets system volume to 100% and scales _both_ apps to match > this one. That is not correct. PA will set streams it doesn't know to 100% of the 'reference volume'. The reference volume is the one you configure on the sink with the UI. i.e. if you change the sink volume to 75% then a new previously unknown stream will be configured to 75%. However if you set the sink volume only indirectly to 75% (i.e. by controlling setting a stream volume to 75% with it being the highest volume) then the referece volume won't be changed and hence new streams will be set to hatever was the reference volume before. > My apps are scaling fine, but here's the problem: "main system > volume" is meaningless. I have no control over it, since Pulse will > set it to whatever it wants. There's no point in even changing it -- > I should just merely set the per-app volumes and let Pulse figure out > what to do. That's not true. Just set the sink volume to whatever you want. All stream volumes are relative to that. > I don't have my laptop plugged into a stereo system with a big volume > knob that I can turn. When I set the main volume to 80%, I want it to > stay that way. I don't want something like playing a YouTube video or > playing a new CD to change the volume back to 100% or whatever it > wants. It seems you first set the sink volume to 80%, then set the stream volume of youtube to 100%. This will then be remembered as "set youtube to 125% of the sink volume". > In essence, the user should be able to set the volume of any program > he likes, and expect that the system will respect that. > > One solution. > 1. When a new never-seen-before app is launched, Pulse defaults not > to 100% but to the current system volume. Which is what happens. We call that "reference volume" however. > 2. Pulse should never change the main system volume on its own. > That's mine. PA won't touch the reference volume. What it will do is touch the virtual volume. > 3. If I change the loudest App, then Pulse may change the main system > volume to match. But only because I did it; whenever an App starts on > its own, Pulse matches it relative to the main system volume. That's exactly what happens, with the exception that we apply it relative to the 'refernce volume', not the 'virtual volume'. > This, in fact, is the way Windows Vista behaves. Pulse currently > doesn't behave like Windows Vista: nothing ever changes your main > volume on Windows except you, or unless *you* change the highest > volume app. WHich is exactly what happens in PA. With the exception that we save/restore the relative volume of each stream- > It's also worth noting that System Sound Events are shown as an App in > the Windows Vista list (unlike Pulse, where they are separate) -- Uh? pavucontrol shows system events as a slider on the "Playback" tab where all the other pp streams are shown too. If you are speaking of g-v-c, please file a bug against gnome-media. I think the big confusion stems from the fact that PA distuingishes "reference" and "virtual" sink volumes, but this distinction is not really visible in the UI which only shows the latter, but can be used to control the former. To clear this a bit up, here's another try at an explanation: 1. The reference volume of a sink is the one all relative stream volumes use as base. It is never changed automatically -- it is only changed by user intervention, such as changing the sink volume slider in the UI. 2. The virtual volume of a sink is the maximum of all stream volumes attached to the sink. It is as such always calculated dynamically and can only be controlled by changing stream volumes. Volume control UIs show the sink's virtual volume in the sink slider. You can change the reference volume by changing the sink slider position. In which case the volume of all sink inputs is adjusted in a way that the virtual volume will match the reference volume. You can change the virtual volume also by changing the stream slider positions, which then doesn't have any effect on the reference volume. Now, I must admit that this all is a bit hard to grasp. And thus not exactly the definition of easy to use. We had a couple of discussions on this very ML about this. So far noone came up with a way to fix this in a way that would be completely convincing. I think the core problem is that it is impossible to figure out what the user actually wants. When he increases a volume of a stream he might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time or B) want it a bit louder because everything that's playing is just too silent and he would be pissed off if only one stream would get louder and not all. And this problem then spills into everything we have: into the persistance logic, into the UIs (where we don't know what slider to show to the user) and so on. The only option we have is probably to make a clear decision and accept that it might appear unintuitive to some. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ pulseaudio-discuss mailing list email@example.com https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss