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

[David Henningsson]

(Sorry for the late answer, forgot about it during the vacation)

On 2014-07-04 14:06, Tanu Kaskinen wrote:
> On Tue, 2014-07-01 at 13:16 +0200, David Henningsson wrote:
>> It's more common than not to have volume bundled with a mute: almost all
>> sinks, sources, and streams have that. Therefore, it feels logically
>> more correct to keep them together, rather having every GUI having to
>> link them together themselves.
>>
>> That said, I do acknowledge that there are valid use cases, especially
>> for mutes without volumes. But it the answer to that really to separate
>> *all* mutes from *all* volumes?
>
> My proposal is that yes, that is the answer. I see the point of
> optimizing for the common case, though, so you could give a more
> concrete proposal that covers also cases where there is only one of
> volume and mute. Just adding a mute field to pa_bvolume doesn't work,
> because it doesn't cover the only-one-or-the-other cases.

Ok, here is what I think it could look like (I don't remember if you had 
another names for cvolume and master_volume):

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? */
     int volume_is_linear; /* better name for convertible_to_dB */

     /* Potentially add more advanced capabilities stuff here, like 
n_volume_steps, or even a value for every step. */
}

The idea is that pa_cvolume is the "bare minimum" struct and the 
pa_bvolume is the "extra everything" struct. Does that make sense?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic