[pulseaudio-discuss] RFC: New volume functionality for PulseAudio
Alexander E. Patrakov
patrakov at gmail.com
Mon Feb 17 09:34:05 PST 2014
17.02.2014 16:36, Arun Raghavan wrote:
> (Resend including list as well)
> On 17 Feb 2014 09:30, "Arun Raghavan" <arun at accosted.net
> <mailto:arun at accosted.net>> wrote:
> We have 3 orthogonal issues here:
> 1. Addition of volume control objects / information to allow balance
> to be represented adequately
This is not limited to balance information. Please split this issue, see
the other half below.
> 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
OK, ignoring (2) and (3) in this e-mail.
> 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.
As far as I understood Tanu's explanations, the problem is that there
are the following assumptions currently hard-coded into PulseAudio:
1. every volume belongs to either a source, or a sink, or a sink input,
or a source output;
2. it belongs to exactly one such object;
3. every such object has exactly one volume.
A sensible model has been demonstrated (as a replacement of the current
logic) that doesn't fit into those assumptions. E.g. (here I am
deliberately trying to "misinterpret" and/or augment the earlier e-mails
by Tanu, just to see if this modification breaks any of his own
A. For each sink, there are two volumes: "System" and "Entertainment".
None of them can be said to be the system's main volume. An attempt to
read or adjust the sink's volume via legacy tools follows the usual
flat-volume logic and changes both.
B. These volumes exist and are adjustable via new tools even if nothing
is playing through that sink.
C. Any stream playing through a sink does not have an
independently-adjustable volume. It effectively assumes one of the
"System" or "Entertainment" volumes belonging to the sink, depending on
its media role. An attempt to read or change the stream volume via
legacy interfaces reads or adjusts one of the "System" or
"Entertainment" volumes belonging to the sink, as appropriate.
Here, (A) breaks (3) for sinks and (2) for streams, (B) breaks nothing
else (but, if these volumes were global instead of per-sink, it would
break (1)), and (C) breaks (2) and (3) for streams.
So, Tanu tries to introduce a volume object, as an entity to represent a
volume that Just Exists (potentially, independently from streams, sinks
and sources), has a human-readable label, and methods to enumerate all
such volume objects.
I hope this e-mail helps you better understand the "Addition of volume
control objects" issue that you brought up. Sorry if this ends up
misrepresenting the idea.
Alexander E. Patrakov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss