[pulseaudio-discuss] RFC: New volume functionality for PulseAudio
Alexander E. Patrakov
patrakov at gmail.com
Thu Feb 13 21:49:28 CET 2014
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
> 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
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
> 3) Streams have independent volumes in cascade with the volume class
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
More information about the pulseaudio-discuss