18.02.2014 22:12, Arun Raghavan wrote: > On 17 February 2014 23:04, Alexander E. Patrakov <patrakov at gmail.com> wrote: > [...] >> 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. > I see these falling under volume classes, rather than multiple > controls for each device. > >> B. These volumes exist and are adjustable via new tools even if nothing is >> playing through that sink. > I don't follow - what volumes are you talking about here? The "System" and "Entertainment" volumes. > >> 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. > Again, this is to do with volume classes and not volumes being > represented as objects on the server. I hope the difference I'm trying > to draw between the two is clear? Not yet. Let me guess. Are you trying to say that "volumes that Just Exist independently of streams and sinks" are in fact volume classes? If so, then yes, the distinction is clear, but the problem of enumeration of all independently-controllable volumes remains. -- Alexander E. Patrakov
