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. > 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. -- Tanu
