13.02.2014 15:25, Tanu Kaskinen wrote: > On Wed, 2014-02-12 at 02:14 +0600, Alexander E. Patrakov wrote: >> 11.02.2014 20:03, Tanu Kaskinen wrote: >>> * Volume classes. A car manufacturer may want to present only two >>> volume controls for the user: "system" and "entertainment". A policy >>> module in PulseAudio should classify streams based on whether their >>> volume should be controlled by the "system" volume or by the >>> "entertainment" volume. The volume classification should be separate >>> from the routing classification (module-stream-restore, among other >>> problems, doesn't allow separate classification for volume and routing). >> >>> * Fine-grained volume UIs that show all application and device >>> volumes, like pavucontrol. PulseAudio already handles this pretty well. >> These two points are definitely valid, but not simultaneously. In a car >> that only allows "system" and "entertainment" volumes, there should be >> no way to create something non-representable in this model by running a >> rich mixer application. All mixer applications should show the same set >> of available volumes. Dumbing down the model must happen in some policy >> module in PulseAudio. In other words, there should be two incompatible >> policy modules: one that implements a dumb model with only two volumes >> applying to all streams according to their system/entertainment class, >> and one that implements a more-traditional per-stream and per-sink >> volume model. > I don't know if we have any actual disagreement here, but just to > clarify: I think it's fine to have dumbed-down and fine-grained > interfaces "simultaneously". Yes, the real granularity is decided by a > policy module in PulseAudio, but applications are free to represent the > controls as they wish. My initial wording on different mixer UI coexistence was overly aggressive, and it did contain a disagreement. However, now I understand that all that would happen in the cases relevant in practice is limited to either having duplicate controls that move together, or a mixer displaying a (possibly empty) subset of all controls if it is running on a policy module it was not designed to work with. This cannot lead to any conflicts or ambiguous situations, and thus, in my new opinion, this is acceptable. > If there are many streams but only few volume > classes, there are three ways to do it: > > 1) Streams reference the volume class volume control. Applications can > show per-stream volumes if they want, but the stream volumes won't be > independent. This looks logical and useful. > 2) The volume control reference in streams is null. Applications can't > show per-stream volumes. This looks just as logical, but less useful than (1) in the sense that a purely stream-oriented mixer interface will display an empty set of controls. > 3) Streams have independent volumes in cascade with the volume class > volume. This invalidates the whole point of having only a few volume classes. If people want this, they should use a separate volume policy module that provides such combined model. I have also reread the API page, and I think that it would be nice to specify event ordering and/or introduce a Sync event that is fired after a group of related changes (the idea comes from the SYN_REPORT event in the input subsystem). Suppose that there is a mixer interface that wants (independently of any policy module) to display all volume controls, grouping them into two tabs: "routing nodes" and "everything else" (just for illustration). To do so, it would listen for RoutingNodeAddedEvent and VolumeControlAddedEvent (and the corresponding removals). On getting a VolumeControlAddedEvent, there is no way to decide on which tab to put this control. One solution would be to always put it onto the "everything else" tab, and move it if the corresponding RoutingNodeAddedEvent is emitted. But that is not flicker-free. With the Sync event, one would be able to avoid updating the GUI until getting it. -- Alexander E. Patrakov
