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>
