Alsa-Devel Archive on
 help / color / Atom feed
From: Jaroslav Kysela <>
To: Tanu Kaskinen <>,
	General PulseAudio Discussion
	alsa-devel <>
Subject: Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
Date: Sun, 23 Feb 2020 14:55:00 +0100
Message-ID: <> (raw)
In-Reply-To: <>

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:
>>>>> +
>>>>> 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 Kysela <>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-15  6:29 Tanu Kaskinen
2020-02-15 16:25 ` Jaroslav Kysela
2020-02-16  9:42   ` Tanu Kaskinen
2020-02-16 10:06     ` [alsa-devel] [pulseaudio-discuss] " Tanu Kaskinen
2020-02-16 17:38       ` Jaroslav Kysela
2020-02-22  6:53         ` [pulseaudio-discuss] [alsa-devel] " Tanu Kaskinen
2020-02-23  9:00           ` Tanu Kaskinen
2020-02-23 13:55             ` Jaroslav Kysela [this message]
2020-02-26  8:05               ` Tanu Kaskinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Alsa-Devel Archive on

Archives are clonable:
	git clone --mirror alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ \
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone