[alsa-devel] [pulseaudio-discuss] Question about the various mixer options in UCM

[Tanu Kaskinen]

On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote:
> + pulseaudio-discuss at lists.freedesktop.org
> 
> On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote:
> > Dne 15. 02. 20 v 7:29 Tanu Kaskinen napsal(a):
> > > What's the difference between PlaybackVolume, PlaybackMixerElem and
> > > PlaybackMasterElem? Other than the obvious difference that
> > > PlaybackVolume is used only to configure the volume control, whereas
> > > PlaybackMixerElem and PlaybackMasterElem are used also to configure the
> > > mute control.
> > 
> > At first, I don't really know if someone uses PlaybackVolume/PlaybackSwitch. 
> > It was defined for the direct control interface (not the mixer interface). I 
> > do not think that we should support this.
> 
> PlaybackVolume/Switch is currently defined for PandaBoard,
> PandaBoardES, SDP4430 and sof-hda-dsp. Do you mean those definitions
> should be removed and replaced with PlaybackMixerElem? It seems that
> PlaybackVolume and PlaybackSwitch don't always match the same simple
> mixer element (e.g. PandaBoard), so I'm not sure if it's possible to
> use PlaybackMixerElem with those platforms.
> 
> As you know, PulseAudio added support for PlaybackVolume recently.
> Should we remove the support? I'm not against that, if
> PlaybackMixerElem is the canonical way to control volume.
> 
> AFAIK CRAS is a major user of UCM, are there others? I think the CRAS
> developers' opinion would be very useful here.
> 
> > I defined new PlaybackMixerElem to select the simple mixer element which 
> > controls both volume and switch (mute) in the ALSA API. The master volume 
> > might be also in the chain (thus PlaybackMasterElem) was introduced.
> > 
> > It seems that it might be not enough and I play with an idea to build custom 
> > mixer description to handle the special cases (like several speakers with the 
> > different volume controls connected to the single stereo stream etc.).
> > 
> > To keep things simple, I would probably hide all functionality to 
> > PlaybackMixer/PlaybackMixerElem and CaptureMixer/CaptureMixerElem . The 
> > special mixer name will create the abstract mixer for the applications and 
> > only one simple mixer element control will set the appropriate volume for
> > the stream (like pulseaudio actually does for the legacy ALSA support - volume 
> > synthetizer). So UCM will describe the mixer for alsa-lib and application will 
> > use only abstract interface to set / get the volume and mute state.
> 
> Hiding everything behind an abstract mixer element sounds VERY good,
> but how to handle a situation where the application uses two devices at
> the same time and the devices share a volume control? For example, a
> phone playing a ringtone to both headphones and speakers. If the
> headphone output has its own abstract mixer element and the speaker
> output has its own abstract mixer element, the application may imagine
> that it can change the volumes independently, but if the outputs share
> a master volume control that is used by both abstract volume elements,
> the volumes aren't really independent, and the resulting volumes may
> not be what the application intended.
> 
> > Actually, I am also trying to resolve the description of the speaker 
> > configuration. It may not be only enough to give the PCM device, because we 
> > don't know, if user connected the stereo or surround speakers to the sound 
> > card output for example. I play with an idea to add device variants to UCM, 
> > but the question is, how we can map this to pulseaudio profile/port schematics.
> > 
> > My quick idea is to export those variants via the verbs, so the exported verb 
> > names might look like:
> > 
> > HiFi:Speaker-Stereo
> > HiFi:Speaker-5.1
> > 
> > Where 'HiFi' is the verb name, 'Speaker' is the device name and 'Stereo' is 
> > the variant name.
> > 
> > If we need to define multiple variants, all may be exported like:
> > 
> > HiFi:Speaker-5.1,Mic-4.0
> > 
> > Also, we can enhance this and store the configuration to a file, thus 'HiFi' 
> > can refer to 'HiFi at Speaker-5.1,Mic-4.0' by default.
> 
> Verb + list-of-device-variants sounds like a good way to map UCM
> devices to pulseaudio profiles (and if there's just one verb, which I
> expect to be the common case, don't show it in the profile name). I
> don't know how the variants should be configured in UCM, but I know
> that device variants should be able to declare conflicts with other
> devices (or device variants). For example, 5.1 speaker output may make
> recording impossible, while stereo speaker output can be used toghether
> with a mic. If this information is not provided by UCM, pulseaudio will
> have to probe all variant combinations (like it currently does with the
> legacy mixer system).

Sorry, now I realized that the Verb + list-of-device-variants scheme
doesn't really work after all as the profile scheme. Or maybe it does,
but it's significantly different from what we do currently. Switching
between Headphones and Speaker-Stereo often doesn't require reopening
the PCM device, so there's no need for separate Headphones and Speaker-
Stereo profiles. I guess we could still create separate profiles, it
just means that the profile list will get much longer.

We could add a separate optimization step to the profile creation
process. That is, first create all possible device-variant combinations
as the initial profile list, and then inspect which profiles can be
merged. Naming the merged profiles becomes a problem, but I imagine
it's solvable with static rules (e.g. merging Speakers-Stereo and
Headphones becomes Analog-Stereo), and if necessary the merging can be 
improved gradually over time.

>From profile creation perspective the ideal scheme would be not based
on UCM devices but on PCM devices and their configuration variants, but
I imagine naming would be an even bigger problem with this scheme (how
to map PCM device names to sensible user friendly names?).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk