[pulseaudio-discuss] RFC: New volume functionality for PulseAudio

[Alexander E. Patrakov]

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 [1], 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 
mixer application).

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 
discussion.

>
> 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:

http://www.patrickbaudisch.com/publications/2004-Baudisch-CHI04-FlatVolumeControl.pdf

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 
become necessary.

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 
volume model.


>
> 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