On 11 February 2014 19:33, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: [...] > The alternative for separate volume controls is that we keep embedding the > volume in various other objects, like sinks, sources, ports (which, btw, are > currently missing volume control altogether when they are inactive), sink > inputs and source outputs. This is certainly a possible approach, but I very > much prefer the separate volume control object idea. > > Benefits of separate volume control objects: > * Solves the problem of figuring out what the main volume controls. For > example, the Gnome volume applet shows a headphone icon when the main volume > controls the headphones volume. The volume applet can check if the main > volume points to the same volume control object as the headset port. This is a bit clumsy, imo (mixers having to iterate over devices to find which one they're controlling), and more importantly, forces the policy to be "main volume == some device volume", which might not be the case. For example, on a phone, the main volume might end up corresponding to the volume of some volume class (music if there's music playing, ringer if there isn't, etc.). > * If two streams share the same volume, a pavucontrol-like application can > group the two streams under one volume slider. I assume you mean for cases such as virtual sink-inputs and source-outputs that we use for filters? These aren't meant for the UI anyway. > * Opportunity to separate the overall volume from the channel balance. The > pa_cvolume volume representation loses all balance information when the user > slides the overall volume to zero. As already discussed, this doesn't really need the volume to be an object. > * Flexibility to easily add new volume control objects for whatever purpose > in the future. For example, there could be a volume debug mode where the > individual alsa volume elements would be exposed as read-only volume > controls, or separate read-only volume control objects for the "reference", > "real" and "soft" components of sink volumes. pactl could show and control > all volumes without understanding what the volumes are associated with. Since I don't really see the volume objects as being needed for the reasons you stated above, I'm not keen on adding them for potential future use. Cheers, Arun
