On Tue, 2014-06-24 at 12:37 +0530, Arun Raghavan wrote: > On Thu, 2014-06-19 at 13:22 +0300, Tanu Kaskinen wrote: > > Hi Arun, > > > > I need to start planning the upstreaming of the volume control concept. > > Currently it's blocked, because you never agreed to introducing volume > > control objects to PulseAudio, and the discussion stopped before > > reaching conclusion. Would you be able to continue the discussion? > > Could you summarise what it is you would like to upstream, specifically > in terms of what the API you're adding would look like? I think I > understand what you're trying to accomplish, but it's not clear how > usable this idea would be in real clients, so having a more concrete > idea of what you're trying to add might help that. Ok. What I'd like to get in upstream in the first phase are volume and mute controls. The controls by themselves aren't terribly useful, so to add some useful new functionality, I think the main volume feature and the module for configuring the main volume (and mute) should go in at the same time. The current version of the full client API can be seen here: https://github.com/otcshare/pulseaudio/blob/a8f787028fd6ba819428d5b6accff6ac7e2aedd9/src/pulse/ext-volume-api.h Assuming that we want this stuff in the core, and not in a module like it's done now, the bvolume stuff will be moved to a separate header. The pa_ext_volume_api_state_t enum can be ignored, as well as the connect() and disconnect() functions, because they're not needed if the API becomes part of the core API. The subscription stuff will be merged with the core subscription API. The server info API will be merged with the core server info API. The device, stream and audio group APIs can hopefully be ignored in this first phase of upstreaming. One thing to discuss is how clients can figure out what the main volume controls. The current implementation is what I originally proposed: the information is implied by how the main volume control is associated with other objects. So if a volume control is used as the main volume, and it's also associated with a headphones device, the client can guess that the main volume controls the headphone volume. I have found this to be ambiguous, however, if the same volume control is also used for something else than just the headphones. I think there should be an explicit (optional) attribute in the controls for describing what the control was primarily created for. A volume control that was created for controlling just the headphone volume would set the attribute value to "device:headphones" (the exact representation is a separate discussion). We can also decide to leave this topic to a later phase, and start with a design that doesn't allow clients to reliably figure out what the main volume controls. David suggested merging the volume and mute control implementations at least in the server code. I didn't first quite understand what that would mean in practice, but now that I've worked on the code for a while, I see that David was right. A lot of duplication can be avoided if volume and mute controls share some of the implementation in one way or another. I'm not sure if this should be reflected also in the client API. -- Tanu
