On Wed, 2014-08-06 at 16:42 +0300, R?mi Denis-Courmont wrote: > Le 2014-08-06 16:10, Tanu Kaskinen a ?crit : > > The answer to your question: no, the normal stream volume and the > > relative volume are very tightly tied together (and when flat volumes > > are not in use, they're exactly the same thing). You can't change one > > without affecting the other, and both are expected to be > > user-controlled. > > Then I don't really see how and why the PulseAudio daemon would have to > care about that new volume. > > The browser can simply divide/multiply the stream volume by its > source/sink volume if the flat volume flag is on. You might or might not > want to provide libpulse-level helpers for it, but that's pretty much > it, AFAICT. My original motivation for the new relative volume control was on the server side. When I implemented audio groups, there was a need to form master-slave relationships between volume controls: audio group volume controls could be masters for other audio group volume controls, and also for stream volume controls. Having a master-slave relationship means that when the master volume changes, the same change is propagated to slave volume controls (and also the other way around, so the relationship is more like peer-to-peer, but a hierarchical structure makes the traversal easier when propagating the changes). I got frustrated when it turned out to be rather complex to propagate the volume between audio groups and streams. I expected the operation to be simple, but since the audio group volume represents the relative volume, I had to add special casing to the propagation code in case the slave was a stream volume control. When doing master->slave propagation, I'd have to check if the slave was a sink input or source output, check whether the sink or source had flat volume enabled, and if so, remap the sink/source volume to the stream channel map, then divide the propagated volume by the sink/source volume, and finally call pa_control_set_volume() on the slave volume control. When doing slave->master propagation, similar dance is needed. With a separate relative control the propagation is very simple. I'm not sure that the separate relative volume control approach results in fewer lines of code, but I like it for several other reasons: * The volume control code doesn't have to do any special casing depending on what the control is being used for. * The volume controls that share the volume with each other have the exact same volume instead of stream volume controls being affected by the sink/source volume. * The stream relative volume is visible in "pactl list volume-controls", which can be nice for debugging. This could be achieved also by implementing the flat->relative conversion logic in pactl, but with the separate relative volume controls this feature comes for free. * If the relative volume controls are exposed to clients, implementing that is much simpler than some kind of libpulse-only helper thing that would have to make an extra round-trip for getting the sink/source state and do the volume calculations. -- Tanu
