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

[Alexander E. Patrakov]

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
>     objects.
>

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 
assumptions):

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...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20140217/18659fa9/attachment.html>