Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a):
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.
This is something which should UCM take in the account. In this case, the
"common" parts should be probably set to a maximum value (or the safe maximum
value) in UCM. Another way is to mark those devices as "conflicting", thus the
I/O won't be used simultaneously.
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?).
I think that I didn't explain my idea in detail. The variant verbs may be
almost identical (thus all devices will be defined) like the "master" one. But
the specific variant configuration will be returned to the application. So it
will differ only in the channel count value for the Speaker device or so. The
PCM device name + PCM parameters check will be fine. I don't think that we
should modify something on the PA side. PA activates only one verb per
soundcard now.
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
