2014-2-15 下午5:08 於 "David Henningsson" <<a href="mailto:david.henningsson@canonical.com">david.henningsson@canonical.com</a>> 寫道： > > On 02/14/2014 01:51 PM, Tanu Kaskinen wrote: > > On Fri, 2014-02-14 at 11:55 +0100, David Henningsson wrote: > >> On 02/14/2014 10:49 AM, Tanu Kaskinen wrote: > >>> Does the grouping have any benefits? If pa_volume_control_info has a > >>> field with this pa_cvolume2 type, then it could be argued that for > >>> symmetry there should also be function > >>> pa_context_set_volume_control_volume() that takes a pa_cvolume2 struct > >>> as a parameter. However, when an application sets the attributes of a > >>> volume control object, usually it will only modify the overall volume or > >>> the balance, not both, and the channel map is immutable, so passing a > >>> pa_cvolume2 struct to the setter function is inconvenient. > >> > >> A volume control UI with presets would typically set both. So would any > >> volume control UI do that does not look exactly the way you anticipate. > >> > >> E g, pavucontrol has two sliders, one left and one right, and gnome > >> volume control has main volume + balance. > > > > I thought about pavucontrol, but not thoroughly enough. I thought that > > if you change only one channel, only balance needs to be changed, but of > > course that only works if the channel in question isn't the highest > > volume channel. > > > >> The grouping would also enable potential helper functions such as those > >> we have for pa_cvolume today. > > > > Good point. > > > > I think grouping the overall volume, the balance and the channel map > > together makes sense. About the struct naming: do you know what "c" in > > "cvolume" refers to? I would guess that it means "channel". pa_cvolume > > very concretely has per-channel volume (a pa_volume_t value for each > > channel). It could be argued that pa_cvolume2 is more balance-oriented > > than channel volume oriented, so here's an idea for a name without > > numbers: pa_bvolume. Thoughts? > > Sure, pa_bvolume sounds as good as anything else to me. > > >>> I'd like to keep mute controls completely separate from volume. They are > >>> not inherently linked to each other (even though they very often appear > >>> together). > >> > >> I don't understand this argument. A mute control *is* a volume control > >> (with two distinct values). the volume control of some dac which have no independent mute switch but mute is implemented at minimum SNDRV_CTL_TLVT_DB_MINMAX_MUTE For this kind of volume control, You lost the original volume after mute and unmute You also need a hardware button to toggle those independent mute switch Even when the sound card provide independent mute switch, the platform may decide not to expose these mute switch to ordinary application , e.g. moblie phone can use the mute switch when user select virbate mode and unmute when the user switch to normal without affect the volume