Bug 1846787 - Greenfield system installation usability concern: discoverability of possibly a vital package alsa-ucm for not being hooked anywhere visibly
Summary: Greenfield system installation usability concern: discoverability of possibly...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: alsa-utils
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Kysela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-14 09:33 UTC by Jan Pokorný [poki]
Modified: 2021-06-10 01:13 UTC (History)
1 user (show)

Fixed In Version: alsa-utils-1.2.5-2.fc34
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-10 01:13:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2020-06-14 09:33:44 UTC
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!

Comment 1 Jan Pokorný [poki] 2020-06-14 10:02:43 UTC
s/alsa-full-hw-coverage/alsa-hw-coverage-full/
if there are more mutually categories, like
"alsa-hw-coverage-dedicated-cards" (as opposed to SoC).

Comment 2 Jan Pokorný [poki] 2020-06-16 06:46:15 UTC
4. some sort of expert-guided heuristics, like:

> sound device X was identified to match these criteria:
> - "on-board audio chip" category
> - number of routing ports Y above predefined limit Z
> and no configuration corresponding to alsa-ucm project
> was found; for optimal experience, make sure the respective
> package is installed, or run "FOOBAR" to suppress this
> message in the future

i.e. similar message emitted when alsactl is run upon boot

If there are some rather reliable _generic_ criteria for
this decision, I think it would be least-effort-most-gain
resolution here.  But of course, it could mix rather well
with any other discoverability enhancing point above

Comment 3 Ben Cotton 2020-08-11 13:38:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 4 Fedora Update System 2021-06-04 07:44:10 UTC
FEDORA-2021-e53b66a8c6 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e53b66a8c6

Comment 5 Fedora Update System 2021-06-05 01:09:32 UTC
FEDORA-2021-e53b66a8c6 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e53b66a8c6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e53b66a8c6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2021-06-10 01:13:10 UTC
FEDORA-2021-e53b66a8c6 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.