Re: UCM: two devices that exclude a third but not each other

On Mon, Aug 24, 2026 at 4:37 PM Jaroslav Kysela <[email protected]> wrote:
>
> You can define multiple verbs one with stereo input and second with two mono
> inputs (mics) - the most easy way is to use Variant blocks to not duplicate
> configurations.
>
> But it may make sense to describe this partial dependency directly with new
> list in the device configuration block (proposal). I am not sure if it will
> work for the current pipewire code - could you check to comment
> verb_dev_list_check() function in alsa-lib and test ?
>
> Also note that your device naming does not follow UCM spec - see usecase.h
> header file [1]. E.g. generic inputs should be named as line. Labels on the
> card should be in comments (for GUI).
>

I tried it. With the second pass of verb_dev_list_check() removed and
nothing else changed, PipeWire gives exactly the two configurations the
card should have:

    Default (Aux, BT, In12, LB12, LB34, LB56, LB78, Line1..Line5, OTG)
    Default (Aux, BT, In1, In2, LB12, LB34, LB56, LB78, Line1..Line5, OTG)

instead of the three it gives today, where each configuration offers
only one microphone. So the current ACP code copes with a partial
relation without any change on its side.

What I removed, for clarity -- only the second pass, the first stays:

static int verb_dev_list_check(struct use_case_verb *verb)
{
/* First pass: ensure bidirectional relationships */
...unchanged...

/* Second pass: complete other relationships for devices
* in group -- removed for this test.
*/
return 0;
}

Nothing else was touched: no changes to parse_device_list(), to
verb_dev_list_add(), or anywhere on the ACP side. I can send the diff
if it is useful.

One caveat about the tooling rather than the code, in case anyone
repeats this: alsaucm prints these lists in pairs, so a list holding a
single entry prints nothing at all and looks like a failure. It cost me
a while before I checked against a device whose list has two entries.

I will try the multiple-verbs form as well, since that is what the
profile can ship today, and it may turn out that a partial list is not
worth a format change if the verb form covers the same ground. If you
would still like the list, I am happy to write it.

And thank you for the naming correction. The card labels will move into
Comment and the devices will be renamed per the spec. Two of them have
no obvious name there and I would rather ask than guess: the card has a
USB-C port carrying audio to and from a phone, which the vendor calls
OTG, and eight loopback return channels that carry the card's own
mixes back to the host. Line with an index for both?

-- 
Thanks,
Mikhail Gavrilov.