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

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Mon Feb 17 02:46:21 PST 2014

On Mon, 2014-02-17 at 16:06 +0530, Arun Raghavan wrote:
> (Resend including list as well)
> On 17 Feb 2014 09:30, "Arun Raghavan" <arun at accosted.net> wrote:
> > On 16 February 2014 16:33, Tanu Kaskinen <tanu.kaskinen at linux.intel.com>
> > wrote:
> > [...]
> > > Yes, I can and I will start the implementation from the volume control
> > > objects, but let's not stop the discussion about volume classes / audio
> > > groups, because I will need to implement a client API for working with
> > > volume classes anyway. The sooner I know how to do it, the better.
> >
> > We have 3 orthogonal issues here:
> >
> > 1. Addition of volume control objects / information to allow balance
> > to be represented adequately

These two things are orthogonal too. The point of volume control objects
isn't that they allow better balance representation. The balance thing
is involved only because if we introduce volume control objects anyway,
it's an opportunity to switch to a better balance representation.

> > 2. Creation and control of volume classes
> >
> > 3. Adding a "main volume" concept
> >
> > I suggest we discuss each in a separate thread to keep the discussion
> > manageable. Right now, I'll address the first, viz. volume control
> > objects.
> >
> > 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.
> >
> > Mainly, I ask this because I don't want to add infrastructure and
> > especially public API for features we don't have yet and don't seem to
> > have a clear path for either (namely controlling equalizer, AGC, and
> > other such parameters)

We have a clear path for one feature: main volume. Alexander and David
supported the idea and the suggested design of the API (add references
from pa_server_info to volume control objects).

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.


More information about the pulseaudio-discuss mailing list