06.08.2014 17:11, Tanu Kaskinen wrote: > On Wed, 2014-08-06 at 16:35 +0600, Alexander E. Patrakov wrote: >> Tanu proposed: >> >>> 3) Add a second volume control to streams, one which represents the >>> stream's own volume only, i.e. never flat volume. Applications that want >>> to avoid flat volume can use that volume control instead of the primary >>> volume control. >>> >>> Even if proposals 1 and 2 are implemented, I'd still like to implement >>> proposal 3 too, because it's simple (I need the second volume control at >>> server side anyway, and adding it to the client API is just a matter of >>> adding one field to pa_sink_input_info and pa_source_output_info) and >>> because it provides some new possibilities for applications: for >>> example, pavucontrol could have an option to not show flat volumes even >>> when flat volumes are enabled. >> >> The idea is well supplanted with a use case, but I think that this could >> use some more discussion. >> >> The potential problem with "just exporting" the field is that the >> proposal specifies only one additional volume factor with no clear >> ownership policy, and I am afraid that various agents (the server and >> the client) will fight over it. OTOH, especially if we design the API to >> avoid "set this extra volume to this value" operation and only allow >> relative changes, this may as well be a non-problem. > > The ownership policy for the new volume control would be the same as > with the current stream volume, i.e. the user is the owner, and volume > changes not originating from user action are most likely a bad idea. I'm > not sure what kind of fight between agents you're thinking of, but with > this ownership policy I think there shouldn't be any conflicts any more > than there is with the current stream volume - stupid applications can > always fight with the user, but the server will only do what clients ask > it to do. OK, I was mistakenly under impression that the "volume changes not originating from user action are most likely a bad idea" policy would not apply to this second control. But, as it applies, there is indeed no fighting. > >> Maybe, instead of having one extra volume control, we need to be able to >> create and destroy additional possibly-invisible volume controls on >> as-needed basis, with the final extra gain determined by the product of >> their volumes? E.g., one volume can be used for volume groups, one can >> be used for ducking when it is in effect, and one for client-specific needs. > > We have server-side capability for this already (see > pa_sink_input.volume_factor_items), what's missing is a way for > applications to create their own extra volume controls for cases where > the user-controlled volume is not appropriate. I think this feature can > and should co-exist with the "second volume control" that I proposed. I agree. -- Alexander E. Patrakov
