[pulseaudio-discuss] RFC: New volume functionality for PulseAudio

[Tanu Kaskinen]

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