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

[Raymond Yau]

2014-2-15 下午5:08 於 "David Henningsson" <david.henningsson at canonical.com> 寫道：
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20140215/ac610724/attachment.html>