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

[Tanu Kaskinen]

On Wed, 2014-02-12 at 02:14 +0600, Alexander E. Patrakov wrote:
> 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.

Thanks for the support! I'm happy that I'm not the only one who sees the
value in this kind of design.

> 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 reason for leaving mute out was not that I'm against mute buttons,
but because nobody has explicitly asked for mute controls (and the gnome
volume applet and the Nokia N9 volume UI, which I used as references,
don't have mute controls). But you're right, the web API should have
mute controls, and I think they should be done in the same way as volume
controls (separate mute control objects, main input and output mute
control references in the AudioSystemContext, and mute classes).

> >  * 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. 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.
2) The volume control reference in streams is null. Applications can't
show per-stream volumes.
3) Streams have independent volumes in cascade with the volume class
volume.

My preference is option 1, but if people want to configure their systems
to use options 2 or 3, I'm fine with that.

-- 
Tanu