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

Mikhail Gavrilov <[email protected]>
Newsgroups gmane.linux.alsa.devel
Message-ID <CABXGCsPVLke4_j-FfGqTMN4tG88G5ckf13_xxKRe=j_w+sWTvQ@mail.gmail.com>
Hi,

A shape I cannot express, on a card where it is the natural one.

The interface has two microphone channels. A UCM profile splits them
into two mono devices, and they work perfectly well at the same time --
two speakers, or a voice and an instrument. The same two channels can
also be taken as one stereo device, which is what you want for a
balanced source arriving on both at once.

So there are two sensible configurations: the two mono devices
together, or the stereo device alone. The stereo device excludes each
mono device; the mono devices do not exclude each other. That is what
I wrote:

    SectionDevice."In1"  { ConflictingDevice [ "In12" ] ... }
    SectionDevice."In2"  { ConflictingDevice [ "In12" ] ... }
    SectionDevice."In12" { ConflictingDevice [ "In1" "In2" ] ... }

and I got three configurations instead of two, each offering only one
microphone. This is what alsa-lib reports back:

    $ alsaucm -c M62 list _conflictingdevs/In1/HiFi
      In2
      In12

In2 is in that list, and nothing in the profile put it there.

verb_dev_list_check() in src/ucm/parser.c explains it. The second pass
adds, for every device D and every target T in D's list, all the other
members of D's list to T's list. So the stereo device listing both
halves makes the halves list each other, and two microphones that can
run together are offered one at a time.

Expressing it the other way round does not escape it. With
SupportedDevice instead, each mono device supporting the other and
everything except the stereo device:

    SectionDevice."In1"  { SupportedDevice [ "In2" "Aux" "BT" ... ] }
    SectionDevice."In12" { SupportedDevice [ "Aux" "BT" ... ] }

    $ alsaucm -c M62 list _supporteddevs/In1/HiFi
      In12
      In2
      ...

In12 is in In1's supported list, and the profile says the opposite. The
closure propagates through shared neighbours: In1 and In12 both support
Line1, so Line1 acquires both, and the pass that adds every other
member of a list to each target hands In12 back to In1.

All three devices then coexist, and on this card that is worse than
useless rather than merely wrong. Their mixer elements overlap -- one
preamp per channel, and the stereo element covers both -- so the nodes
restore different remembered gains over the same hardware. A recording
made that way came back clipped at 0 dBFS with its two channels 12 dB
apart in RMS, while a simultaneous mono take from the same source sat
at -18 dBFS.

Both list types are group relations, then, and a partial relation
cannot be written. A profile has to choose: two mono inputs or one
stereo pair. I have chosen the two mono inputs and said so in the file,
but I would rather describe the card than choose for its owner.

Is there a way to express this that I have missed? If there is not,
would a pairwise form be worth considering -- a list taken as written,
without the closure -- alongside the grouping one, so that existing
profiles keep their meaning?

-- 
Thanks,
Mikhail Gavrilov.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.