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

[Tanu Kaskinen]

On Tue, 2014-07-29 at 21:46 +0300, Tanu Kaskinen wrote:
> On Tue, 2014-07-29 at 14:01 +0200, David Henningsson wrote:
> > struct pa_bvolume {
> >      pa_cvolume cvolume;
> >      double master_volume;
> >      int mute; /* 0 means unmuted, all other values muted */
> >      int has_volume;
> >      int has_mute; /* Should we skip this one? */
> 
> I'd say yes, we should skip it. We can add it later if necessary. Not
> having it makes things simpler for applications. The downside is that if
> we add it later, applications need to be updated, i.e. it's unnecessary
> churn for applications. It seems possible that we will never need to
> have the has_mute field, however.

I now have a case where has_mute may be useful. I create two volume
controls for streams: "normal" and "relative". "normal" can be absolute
or relative depending on whether the current sink is in flat volume
mode, "relative" is always relative. The "relative" controls are used by
audio groups - as I've explained earlier, it doesn't make sense for the
audio group volume to map to absolute stream volume.

There are multiple ways to deal with this:

1) Have mute only on the "normal" or the "relative" control, not both.
This requires the has_mute flag.

2) Have mute on both controls, reflecting the same state. This doesn't
require the has_mute flag.

3) Don't have the "relative" control at all, try to convert between
relative and absolute on the fly when audio groups interact with streams
(it's not as simple to do as it sounds). This doesn't require the
has_mute flag.

I don't have a strong opinion between 1 and 2, but I like 2 a bit more,
because if a client chooses to use the "relative" control instead of the
"normal" control, the stream mute state will be easily accessible. I
don't like option 3.

I haven't so far added a relative_volume_control field to
pa_sink_input_info in the client API, because it has only been needed at
server side, but I think it would make sense to add that field. Clients
may want to avoid flat volume for their streams, and the separate
relative_volume_control field would make that easy.

Any other opinions?

-- 
Tanu