[pulseaudio-discuss] RFC: New volume functionality for PulseAudio
Alexander E. Patrakov
patrakov at gmail.com
Tue Feb 11 21:14:55 CET 2014
11.02.2014 20:03, Tanu Kaskinen wrote:
> Hi all!
> I'm working (together with other people at Intel) on adding system
> volume control functionality to Tizen (primarily the IVI profile,
> although there's nothing inherently IVI specific here). Tizen uses web
> APIs for the UI, and since there are no existing web API standards for
> this functionality, we need to design the API from scratch. The
> current design can be seen at , in case you're interested (it's
> good background material for this discussion). What I'd like to
> discuss in this thread, however, is not the web API as such, but the
> use cases behind that design and what those use cases ultimately
> require from PulseAudio. (Feedback for the web API proposal is welcome
> too, but I think that should be discussed in a separate thread.)
Thanks for taking this to the mailing list.
I have read the linked web page, and I must say that I support the ideas
about input volumes expressed there. Very nice design, with the "slider
moved" (VolumeChanged) and "there is a different slider that wants to
represent the default volume" (MainInputVolumeControlChangedEvent)
events separated. And here is why I think this is good. Sooner or later,
someone will implement optional and runtime-switchable automatic gain
control (AGC). A natural question is: does the whole notion of the main
input volume make sense at all if AGC is enabled? If the answer is "no"
(as I expect), your design can accommodate that naturally, by emitting
the MainInputVolumeControlChangedEvent event and setting the
main_input_volume_control attribute of the AudioSystemContext to null if
AGC is enabled.
As for one of the open questions:
> Do we need to add mute controls, or are volume controls sufficient at
> this point?
Mute controls are of course needed! Otherwise, there would be no way to
implement the mute button correctly. Imagine the following use case on a
laptop (assuming that input volumes persist over a reboot).
1. The user starts the mixer application and goes to the input
(microphone) level. It shows some good input volume using a slider, and
also has a mute button.
2. The user mutes the microphone using the mute button.
3. The user reboots the laptop.
4. The user starts the mixer application. Now it has to show that the
microphone is muted, and also somehow indicate what the input volume
would be if it is unmuted. And, of course, restore the volume to the old
known-good value when the user clicks the mute button again.
Now the problem is where to get that would-be-volume. Without the
explicit mute controls in PulseAudio, the only answer to that would be
application-specific storage, which looks bad e.g. due to interaction
problems between two mixer applications, due to the possibility of the
inconsistent state where the mixer application has a stored volume for
the microphone while it is actually not muted, and due to the very fact
that volume is stored in two places (in PulseAudio itself and in the
OTOH it is easy to punt the problem by saying "there should be no mute
buttons, any attempt to make one is a bug", which is a valid viewpoint,
but I disagree with it :)
> The first question: do you agree that PulseAudio should support those
> use cases in one way or another?
Yes, but I think that the first point below could use some further
> We want to support:
> * A single main output volume control. Think of things like the Gnome
> volume applet: when you click the applet icon, you get a single volume
> slider for controlling the "current output", whatever that means. The
> Gnome volume applet implements the main volume by using the default
> sink volume, but we'd like to make the main volume contextual, so that
> the main volume can control different things at different times.
> Ideally the contextual logic would be implemented in PulseAudio (by a
> policy module), not in the volume applet. The volume applet should
> know when the main volume controls e.g. the headphones volume or the
> phone call volume.
I tried to answer this with the following worry: the main volume may be
something to which the usual slider-based paradigm and the corresponding
"get and set a floating-point value" does not necessarily apply. In
particular, I was going to talk about the "thumbwheel" from the paper
that the proponents of flat volumes use as their scientific basis:
A thumbwheel in this context is something that, by design, does not have
a current value, but can be moved by a specified amount (e.g. affecting
all streams connected to a sink by the same amount). However, PulseAudio
already implements a "flood mark" idea from the same paper, thus
effectively pushing this into the slider-oriented API, so my worry that
we might need an increment-based API with no "get" looks unfounded so
far. But the part of PulseAudio logic where the flood mark becomes the
default volume for new streams doesn't correspond to anything in the
article - if this assumption is removed, an increment-based API might
Anyway, while trying to write a reply, I concluded that I need to think
more on this topic. I will probably write a separate e-mail about this
later, but don't hold the discussion on this. No reply from me in 48
hours = please forget this worry.
> * 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
> Streams could have their own volume control objects, or multiple
> streams could reference the shared volume control of their volume class.
Yes, that's the same idea.
> The alternative for separate volume controls is that we keep embedding
> the volume in various other objects, like sinks, sources, ports
> (which, btw, are currently missing volume control altogether when they
> are inactive), sink inputs and source outputs. This is certainly a
> possible approach, but I very much prefer the separate volume control
> object idea.
... because of ...
> * Flexibility to easily add new volume control objects for whatever
> purpose in the future.
For me, this is a very solid argument that is sufficient by itself.
Think about not-currently-playing streams like event sounds and saved
volumes for the past streams.
Alexander E. Patrakov
More information about the pulseaudio-discuss