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

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

[Tanu Kaskinen]

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.

-- 
Tanu

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about the various mixer options in UCM

[Jaroslav Kysela]

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.

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.

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.

I welcome any opinions on this. The goal is to provide the complete abstract 
description of the sound hardware for sound servers like pulseaudio. We can 
use this abstraction for the command line ALSA applications, too.

				Thanks,
					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about the various mixer options in UCM

[Tanu Kaskinen]

+ pulseaudio-discuss@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@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).

-- 
Tanu

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [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@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@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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Jaroslav Kysela]

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

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@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Tanu Kaskinen]

On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote:
> 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@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.
> 
> 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.

Hmm, in my example I assumed (but I didn't say) that the headphones and
speaker use the same PCM device. In this case the devices will be
marked as conflicting anyway, which I didn't take into account, so if
an application nevertheless wants to use both outputs, there needs to
be a separate headphones+speaker device, which can set up the volume
control in a sensible way. The application won't have control over the
independent volumes, unless some new UCM feature is invented, but
that's a separate issue. In conclusion, in this case the abstract
element idea works well.

If the PCMs are separate, I guess it's less likely that the two devices
will share a master volume control.

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

Oh, you want to create variant verbs? Is the idea that all possible
device combinations will be made separate verbs? That would make life
easier for PulseAudio, but wouldn't it mean a lot more work for UCM
configuration writers? Rather than generating the device combinations
automatically in PulseAudio, the combinations would have to be manually
listed in every UCM configuration.

I think it would be better to define only one verb per sound card and
declare the conflicts between the devices or device variants, and let
PulseAudio automatically generate the device combinations as profiles.

I may be misunderstanding something, I didn't for example understand
what you meant by "the PCM device name + PCM parameters check will be
fine". Some examples could be useful. Let's say that there's a sound
card that has stereo output (either headphones or line-out), 4.0
output, 5.1 output, SPDIF output and stereo input. If input is used,
5.1 output can't be used at the same time. Would UCM define the
following verbs?:

HiFi:Headphones,SPDIF,Mic
HiFi:Line-Stereo,SPDIF,Mic
HiFi:Line-4.0,SPDIF,Mic
HiFi:Line-5.1,SPDIF

-- 
Tanu

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

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

[Tanu Kaskinen]

On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote:
> On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote:
> > 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@lists.freedesktop.org
> > > > 
> > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote:
> > > > > 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.
> 
> Oh, you want to create variant verbs? Is the idea that all possible
> device combinations will be made separate verbs? That would make life
> easier for PulseAudio, but wouldn't it mean a lot more work for UCM
> configuration writers? Rather than generating the device combinations
> automatically in PulseAudio, the combinations would have to be manually
> listed in every UCM configuration.
> 
> I think it would be better to define only one verb per sound card and
> declare the conflicts between the devices or device variants, and let
> PulseAudio automatically generate the device combinations as profiles.
> 
> I may be misunderstanding something, I didn't for example understand
> what you meant by "the PCM device name + PCM parameters check will be
> fine". Some examples could be useful. Let's say that there's a sound
> card that has stereo output (either headphones or line-out), 4.0
> output, 5.1 output, SPDIF output and stereo input. If input is used,
> 5.1 output can't be used at the same time. Would UCM define the
> following verbs?:
> 
> HiFi:Headphones,SPDIF,Mic
> HiFi:Line-Stereo,SPDIF,Mic
> HiFi:Line-4.0,SPDIF,Mic
> HiFi:Line-5.1,SPDIF

I'm currently writing UCM configuration for Audigy2, because
PulseAudio's default configuration doesn't work with that card
properly. I'm creating verbs for each possible device combination, and
I ran into a naming issue. How should "bidirectional" devices be listed
in the verb name? If there's both line-out and line-in and SPDIF
supports both input and output, maybe the verb name could be for
example this:

HiFi:Line-4.0-Out,SPDIF-Out,Line-Stereo-In,SPDIF-In

The device name in SectionDevice would be just "Line" or "SPDIF".

I don't really like bidirectional devices, i.e. I'd prefer have
separate SectionDevice names for Line-In and Line-Out, but I guess
merging them into one device can work.

-- 
Tanu

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

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

[Jaroslav Kysela]

Dne 23. 02. 20 v 10:00 Tanu Kaskinen napsal(a):
> On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote:
>> On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote:
>>> 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@lists.freedesktop.org
>>>>>
>>>>> On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote:
>>>>>> 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.
>>
>> Oh, you want to create variant verbs? Is the idea that all possible
>> device combinations will be made separate verbs? That would make life
>> easier for PulseAudio, but wouldn't it mean a lot more work for UCM
>> configuration writers? Rather than generating the device combinations
>> automatically in PulseAudio, the combinations would have to be manually
>> listed in every UCM configuration.
>>
>> I think it would be better to define only one verb per sound card and
>> declare the conflicts between the devices or device variants, and let
>> PulseAudio automatically generate the device combinations as profiles.
>>
>> I may be misunderstanding something, I didn't for example understand
>> what you meant by "the PCM device name + PCM parameters check will be
>> fine". Some examples could be useful. Let's say that there's a sound
>> card that has stereo output (either headphones or line-out), 4.0
>> output, 5.1 output, SPDIF output and stereo input. If input is used,
>> 5.1 output can't be used at the same time. Would UCM define the
>> following verbs?:
>>
>> HiFi:Headphones,SPDIF,Mic
>> HiFi:Line-Stereo,SPDIF,Mic
>> HiFi:Line-4.0,SPDIF,Mic
>> HiFi:Line-5.1,SPDIF
> 
> I'm currently writing UCM configuration for Audigy2, because
> PulseAudio's default configuration doesn't work with that card
> properly. I'm creating verbs for each possible device combination, and

Note that variants are not supported in UCM yet. I expect to add the 
VariantSection to the DeviceSection like this:

SectionDevice."Speaker" {
   SectionVariant."4.0" {
     Value {
       PlaybackChannels 4
       ... channel mapping (todo) ...
     }
   }
}

etc.. The alsa-lib will compose the verbs variants. I believe that we should 
not duplicate all verb configs just because one line requires a change.

> I ran into a naming issue. How should "bidirectional" devices be listed
> in the verb name?

If there is a difference between playback/capture parameters or mixer 
settings, you cannot define the bidirectional device. But you can use indexes:

SectionDevice."Line1" {
   comment "Rear line output"
   ...  configuration for line-out ...
}

SectionDevice."Line2" {
   comment "Rear line input"
   ... configuration for line-in ...
}

plus variants.

> If there's both line-out and line-in and SPDIF
> supports both input and output, maybe the verb name could be for
> example this:
> 
> HiFi:Line-4.0-Out,SPDIF-Out,Line-Stereo-In,SPDIF-In
> 
> The device name in SectionDevice would be just "Line" or "SPDIF".
> 
> I don't really like bidirectional devices, i.e. I'd prefer have
> separate SectionDevice names for Line-In and Line-Out, but I guess
> merging them into one device can work.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

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

[Tanu Kaskinen]

On Sun, 2020-02-23 at 14:55 +0100, Jaroslav Kysela wrote:
> Dne 23. 02. 20 v 10:00 Tanu Kaskinen napsal(a):
> > On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote:
> > > On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote:
> > > > 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@lists.freedesktop.org
> > > > > > 
> > > > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote:
> > > > > > > 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.
> > > 
> > > Oh, you want to create variant verbs? Is the idea that all possible
> > > device combinations will be made separate verbs? That would make life
> > > easier for PulseAudio, but wouldn't it mean a lot more work for UCM
> > > configuration writers? Rather than generating the device combinations
> > > automatically in PulseAudio, the combinations would have to be manually
> > > listed in every UCM configuration.
> > > 
> > > I think it would be better to define only one verb per sound card and
> > > declare the conflicts between the devices or device variants, and let
> > > PulseAudio automatically generate the device combinations as profiles.
> > > 
> > > I may be misunderstanding something, I didn't for example understand
> > > what you meant by "the PCM device name + PCM parameters check will be
> > > fine". Some examples could be useful. Let's say that there's a sound
> > > card that has stereo output (either headphones or line-out), 4.0
> > > output, 5.1 output, SPDIF output and stereo input. If input is used,
> > > 5.1 output can't be used at the same time. Would UCM define the
> > > following verbs?:
> > > 
> > > HiFi:Headphones,SPDIF,Mic
> > > HiFi:Line-Stereo,SPDIF,Mic
> > > HiFi:Line-4.0,SPDIF,Mic
> > > HiFi:Line-5.1,SPDIF
> > 
> > I'm currently writing UCM configuration for Audigy2, because
> > PulseAudio's default configuration doesn't work with that card
> > properly. I'm creating verbs for each possible device combination, and
> 
> Note that variants are not supported in UCM yet.

Yes, I know. But if the variants are going to show up as separate verbs
to PulseAudio, I figured I can already get the same effect by manually
creating the verbs.

> I expect to add the 
> VariantSection to the DeviceSection like this:
> 
> SectionDevice."Speaker" {
>    SectionVariant."4.0" {
>      Value {
>        PlaybackChannels 4
>        ... channel mapping (todo) ...
>      }
>    }
> }
> 
> etc.. The alsa-lib will compose the verbs variants. I believe that we should 
> not duplicate all verb configs just because one line requires a change.

Ok, if alsa-lib autogenerates the verbs, that should make things easy
for both configuration writers and PulseAudio, assuming that there's no
disagreement about the verb generation logic. What logic will alsa-lib
use when creating the verbs? There are at least a couple of
alternatives.

I think it would be best to create a verb for every possible maximal
device variant combination. By "possible" I mean that a verb shouldn't
contain any devices (or device variants) that can't be used
simultaneously with other devices in the verb, and by maximal I mean
not to create verbs that are subsets of other verbs.

Another possibility is to follow the current autogeneration logic in
PulseAudio: generate all possible combinations of one input and one
output, plus a verb for each single device variant. I don't think this
is as good as the first alternative (impossible to use multiple outputs
at the same time, and the single device verbs make the verb/profile
list longer). The only reason to do this would be to avoid changes in
PulseAudio (currently some things won't work as expected if there are
multiple outputs in one profile and if the single-device profiles don't
exist).

> > I ran into a naming issue. How should "bidirectional" devices be listed
> > in the verb name?
> 
> If there is a difference between playback/capture parameters or mixer 
> settings, you cannot define the bidirectional device. But you can use indexes:
> 
> SectionDevice."Line1" {
>    comment "Rear line output"
>    ...  configuration for line-out ...
> }
> 
> SectionDevice."Line2" {
>    comment "Rear line input"
>    ... configuration for line-in ...
> }
> 
> plus variants.

Ok, thanks!

-- 
Tanu

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