(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
