Hi Arun,
I need to start planning the upstreaming of the volume control concept.
Currently it's blocked, because you never agreed to introducing volume
control objects to PulseAudio, and the discussion stopped before
reaching conclusion. Would you be able to continue the discussion?
-- Tanu
On Tue, 2014-02-18 at 19:05 +0200, Tanu Kaskinen wrote:
> On Tue, 2014-02-18 at 21:50 +0530, Arun Raghavan wrote:
> > On 18 February 2014 21:41, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
> > > On Tue, 2014-02-18 at 21:26 +0530, Arun Raghavan wrote:
> > >> On 17 February 2014 23:47, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
> > >> > On Mon, 2014-02-17 at 12:46 +0200, Tanu Kaskinen wrote:
> > >> >> On Mon, 2014-02-17 at 16:06 +0530, Arun Raghavan wrote:
> > >> >> > > I'm not completely clear what you're trying to achieve with volume
> > >> >> > > control objects right now - are you just trying to fix the balance
> > >> >> > > problem, or ...? I see the point you're making about the potential
> > >> >> > > applicability of associating multiple volume controls with a single
> > >> >> > > device, but I'd like to understand what you'll be solving with the
> > >> >> > > patch set you'd be submitting with this infrastructure.
> > >> >
> > >> > <snip>
> > >> >
> > >> >> Out of curiosity, what do you mean by "associating multiple volume
> > >> >> controls with a single device"? I don't remember mentioning multiple
> > >> >> volume controls per device, unless you mean the idea of having a debug
> > >> >> mode with access to alsa mixer volume elements etc.
> > >> >
> > >> > Never mind, I now realized that you probably referred to the N9 volume
> > >> > model, where each output device has two volumes: "call" and "everything
> > >> > else".
> > >>
> > >> I'd have thought that would be handled by volume classes, but perhaps
> > >> I'm not following what the N9 is doing.
> > >
> > > Ok, then I'll ask again: what did you mean by "associating multiple
> > > volume controls with a single device"?
> >
> > I was referring to Alexander's mail about potentially controlling eq
> > and AGC on devices via volume control mechanisms.
>
> I think you're mixing things. Alexander mentioned AGC as a case where it
> doesn't make sense to have main input volume at all, and this could be
> expressed by setting pa_server_info.main_input_volume to
> PA_INVALID_INDEX.
>
> I mentioned equalizers as a control type that could be attached to audio
> groups in the future. As a reminder: I came to the conclusion that I
> don't really want volume classes, I want audio groups, which are
> otherwise the same as volume classes, but bundle also mute and routing
> (and potentially equalizer control and whatever other controls are
> useful in the future). An audio group would thus look like this:
>
> struct pa_audio_group_info {
> uint32_t index;
> const char *name;
> const char *description;
> uint32_t volume_control;
> uint32_t mute_control;
> uint32_t routing_node;
> uint32_t equalizer_control;
> };
>
> An audio group does not need to control all those aspects, it can also
> set some of the controls to PA_INVALID_INDEX.
>
> > > As for the N9 setup: there are two volume classes: "call" and "other".
> > > There are 2 * n_output_devices volume controls, one for each combination
> > > of a volume class and an output device.
> >
> > Perhaps we can chat about how the volume control works on the N9
> > (since the phones I've worked with usually have a single output device
> > for normal playback, and some special sauce for phone calls). Unless
> > it's relevant to this discussion, in which case I'm curious to know
> > whether it somehow makes more sense to have two volumes per device,
> > rather than have policy store a per-device-class volume independently.
>
> N9 saves the volume independently for each device/volume class pair. I
> don't know if the devices you've worked with do this.
>
> This model was implemented in N9 by modifying module-stream-restore
> heavily. The resulting code wasn't pretty, but it worked. The benefit of
> volume control objects in this case would be that they can be directly
> mapped to the stored volumes, which is neat.
>
> I'm not saying that I need volume control objects for this particular
> feature, I'm just saying that volume control objects would provide a
> transparent view to what logical volume controls actually exist in the
> system. It can be argued that the stored volumes shouldn't be exposed to
> applications directly anyway, because applications should access the
> volumes only via the two volume classes.
