On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote: > + pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx > > 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@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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
