Bug 1846787

Hello Jaroslav,

as a follow-up to a thread of my desperate attempt to get the sound
working in a particular stuck-without-UCM setup:

https://mailman.alsa-project.org/pipermail/alsa-devel/2020-May/168430.html

or rather as hinted by you at the end of that thread:

https://mailman.alsa-project.org/pipermail/alsa-devel/2020-June/168634.html

I am trying to propose some kind of a scheme to make the link
between "core ALSA" (alsactl, alsalib) more apparent, so that
people are spared the problem I had.

What was already said on the topic per the latter hyperlink:

> The alsa-ucm is installed for the workstation GUIs:
> 
> https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in
> 
> See "Fedora Workstation", "LXDE Desktop", "LXQt Desktop" etc.
> All depends on  the "multimedia" package group which contains
> alsa-ucm.

I don't think it's a convincing argument against leaving it at
the status quo.  There are minimalists environment that don't even
have a compose group, simply because in the little set of packages,
it doesn't make sense to add this administrative overhead.

For example, I'd expect that "dnf install sway pulseaudio" with
a minimal terminal-only Fedora install will "almost" get me to
everything fully functional.  Note that inter-package dependencies
is what shall describe true nature of the dependencies, not that
you mark a bag of packages as a delivery unit.  You could get rid
of RPM dependencies otherwise (one would get away with "use case
bag of packages" approach then :-)

Even installing alsa-utils explicitly is within what a slightly
above average user is able to come up with.  But alsa-ucm appears
to be a stretch, as I could attest myself :-/

I have various (not mutually exclusive) ideas that might help,
unordered:

1. have alsa-lib do Recommends: alsa-ucm

2. assuming that sound devices enumerated in alsa-ucm
   project are "almost" vitally depending on UCM configurations
   for them to work satisfactorily (it was in my case!),
   let's think of some kind a "discoverability" scheme:

2a. something based on the idea of Takashi Iwai:
    https://mailman.alsa-project.org/pipermail/alsa-devel/2020-June/168633.html
    (does it require changes in kernel drives? udev rules?)

2b. an idea of "stub ucm2/ucm.conf"

    looking at
    https://github.com/alsa-project/alsa-lib/blob/v1.2.3/src/ucm/parser.c#L2207
    it seems that, if syntax in that file allows (not sure),
    there could be something like this encoded:

>   if (card known to be tracked in alsa-ucm project
>       and
>       UCM profile for that card not found/loaded
>       at this point [toplevel is run afterwards]):
>   then
>       holler "you are advised to install alsa-ucm package"

    and upon installing alsa-ucm, it would get naturally silenced

    That would likely require the build process of alsa-lib
    to have source of alsa-ucm as well available to peek into
    it so as to generate such necessary rules in ucm2/ucm.conf

    [there are multiple levels of moving parts, perhaps
    /usr/share/alsa/cards/*.conf would work as well]

3. have an alsa-full-hw-coverage or so virtual package that would
   tie these together (i.e. said "bag of packages" approach):
   - alsa-util (brings alsa-lib)
   - alsa_ucm
   - alsa-firmware
   - alsa-sof-firmware
   - ...

   that would apparently be overkill for majority, but godsend
   for the desperate users like I was at one point

Again, the key here would be: discoverability.  And the more
clues on various places, the better, especially if enumeration
of known-to-require-UCM cards is established within wider
ALSA project.  This assumes that majority of UCM profiles are
to render unusable cards effectively usable at all, like in this
P520/RealTek ALC662 case.  No idea about the reality, though.
As already mentioned, two generations of Lenovo ThinkPad did
not require that package to be installed before, so it was
really a new thing to me.

Thanks for considering unadvanced yet admin-capable users!