Thank you for your report. Could you try to downgrade only `alsa-ucm` package ?

Tried. But downgrading only 'alsa-ucm' is not easily possible due to package conflicts:

# rpm-ostree override reset alsa-lib alsa-utils
Checking out tree 51ac923... done
Resolving dependencies... done
error: Could not depsolve transaction; 1 problem detected:
 Problem: package alsa-utils-1.2.12-1.fc40.x86_64 from @System requires alsa-ucm >= 1.2.12, but none of the providers can be installed
  - cannot install both alsa-ucm-1.2.11-2.fc40.noarch from @commandline and alsa-ucm-1.2.12-1.fc40.noarch from @System
  - conflicting requests

(This commands tries to reset the overrides for packages alsa-lib and alsa-utils, but not for alsa-ucm).

Try this manually (install 1.2.12 and downgrade alsa-ucm only):

  rpm -e --force --nodeps alsa-ucm
  rpm -ivh --nodeps alsa-ucm-1.2.11-2.fc40.noarch.rpm

This does not work on Atomic Desktops like Silverblue since /usr is immutable.
According to the man page, "rpm-ostree override" does not seem to support any kind of --force or --nodeps options.

I could install test builds from Fedora Koji/Bodhi systems of the alsa libraries and tools if available and not causing dependency errors.

Ok, we can probably try another way.

Could you show output from `alsaucm -c hw:0 dump text` command (from alsa-ucm-utils package)? I assume that sound card #0 is your internal sound card (hint: `aplay -l`).

Also, please, attach output from `alsa-info.sh --no-upload`.

Created attachment 2037748 [details]
Requested output of alsa commands, version 1.2.11 (working)

Contains the requested output of the commands

alsaucm -c hw:0 dump text
aplay -l
alsa-info.sh --no-upload

on Silverblue 40.20240618.0 with:
  LocalOverrides: alsa-ucm alsa-lib 1.2.12-1.fc40 -> 1.2.11-2.fc40 alsa-utils 1.2.12-1.fc40 -> 1.2.11-1.fc40
  LocalPackages: alsa-ucm-utils-1.2.11-1.fc40.x86_64 

HDMI audio is working with these alsa library versions (1.2.11)

Created attachment 2037749 [details]
Requested output of alsa commands, version 1.2.12 (not working)

Contains the requested output of the commands

alsaucm -c hw:0 dump text
aplay -l
alsa-info.sh --no-upload

on Silverblue 40.20240618.0 without alsa overrides:
  LayeredPackages: alsa-ucm-utils 

HDMI audio is NOT working with these alsa library versions (1.2.12)

alsa RPM versions in Silverblue 40.20240618.0:
 
alsa-lib-1.2.12-1.fc40.x86_64
alsa-ucm-1.2.12-1.fc40.noarch
alsa-utils-1.2.12-1.fc40.x86_64
alsa-sof-firmware-2024.03-2.fc40.noarch
alsa-ucm-utils-1.2.12-1.fc40.x86_64 (layered)

Hints: 
A (vim)diff of the two als-info.sh outputs seems to me quite interesting.
The command "alsaucm -c hw:0 dump text"  fails, printing an error message on stderr

This is the culprit:

  ALSA lib ucm_subs.c:807:(uc_mgr_get_substituted_value) variable '${sys:devices/virtual/dmi/id/sys_vendor}' is empty in this context!
  ALSA lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -22
  alsaucm: error failed to open sound card hw:0: Invalid argument

Thanks.

Does /sys/devices/virtual/dmi/id/board_vendor file exist in your system? Contents?

The problem should be fixed in https://github.com/alsa-project/alsa-ucm-conf/commit/13022a97711daa156c0cc6e5601409a86e5a26ec.

Could you test latest UCM configs? Because you cannot simply replace file in /usr, you can do this (correct $HOME/test paths):

- download latest `curl -L -o alsa-ucm-conf.tar.gz https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar.gz`
- unpack it somewhere (like $HOME/test)
- run `ALSA_CONFIG_UCM2="$HOME/test/ucm2" alsaucm -c hw:0 dump text`

Does it show an error ?

Created attachment 2037817 [details]
Typescript Logs of alsaucm -c hw:0 dump text

Files /sys/devices/virtual/dmi/id/{board,sys}_vendor exist but contain only generic values:

$ cat /sys/devices/virtual/dmi/id/board_vendor
Default string

$ cat /sys/devices/virtual/dmi/id/sys_vendor

(1 Empty line)

I have attached the outputs of "script alsaucm -c hw:0 dump text" from version 1.2.11 and 1.2.12. 

For version 1.2.12 I used the latest suggested and downloaded ALSA config:
ALSA_CONFIG_UCM2=$HOME/Projekte/alsa-ucm-conf-master/ucm2 strace alsaucm -c hw:0 dump text
This command still fails with the same error.

It seems to me that old alsaucm 1.2.11 falls back to a generic HDMI configuration if it can't retreive a dmi vendor or system id:

...
openat(AT_FDCWD, "/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/snd/controlC0", O_RDWR|O_CLOEXEC) = 3
access("/usr/share/alsa/ucm2/ucm.conf", R_OK) = 0
openat(AT_FDCWD, "/usr/share/alsa/ucm2/ucm.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/share/alsa/ucm2/lib/generic.conf", O_RDONLY) = 4
access("/usr/share/alsa/ucm2/conf.d/sof-hda-dsp/Defaultstring---Defaultstring.conf", R_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
access("/usr/share/alsa/ucm2/conf.d/sof-hda-dsp/sof-hda-dsp.conf", R_OK) = 0
openat(AT_FDCWD, "/usr/share/alsa/ucm2/conf.d/sof-hda-dsp/sof-hda-dsp.conf", O_RDONLY) = 4
...

Can this behaviour be restored in ALSA version 1.2.12+?

It seems that the BIOS on this machine is totaly crappy (from alsa-info.sh output):

  !!DMI Information
  !!---------------

  Manufacturer:      
  Product Name:      
  Product Version:   
  Firmware Version:  R6G07
  System SKU:        Default string
  Board Vendor:      Default string
  Board Name:        Default string

Empty everything or "Default string". I fixed only empty "Manufacturer" / sys_vendor case, but not empty "Product Name" / product_name from DMI.

The related config is not HDMI related but it handles coefficients for DSP processing for other I/O (speakers,microphone). Basically the configuration tries to compose an unique path for all hardware variants and uses DMI info as source. If DMI is crappy, it won't work correctly. DMI should be like:

  Manufacturer:      Hewlett-Packard
  Product Name:      HP ProBook 4340s
  Product Version:   A1018C1100
  Firmware Version:  68IRR Ver. F.32
  Board Vendor:      Hewlett-Packard
  Board Name:        17F0

Even if I use "Board Name" fallback for the empty "Product Name", the composed path will be like "/usr/share/alsa/ucm2/blobs/sof/product_configs/Default string/Default string.conf".

Let me think about this.

DMI System Information and Base Board Information tables contain only default values:

# dmidecode -t 1,2
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Not Specified
	Product Name: Not Specified
	Version: Not Specified
	Serial Number: 1123223030335
	UUID: 03000200-0400-0500-0006-000700080009
	Wake-up Type: Power Switch
	SKU Number: Default string
	Family: Default string

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Default string
	Product Name: Default string
	Version: Default string
	Serial Number: Default string
	Asset Tag: Default string
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Default string
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Or:

# grep -r . /sys/class/dmi/id
/sys/class/dmi/id/bios_date:08/05/2022
/sys/class/dmi/id/board_serial:Default string
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnAmericanMegatrendsInternational,LLC.:bvrR6G07:bd08/05/2022:br5.19:efr1.3:svn:pn:pvr:rvnDefaultstring:rnDefaultstring:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:
/sys/class/dmi/id/product_serial:112322xxxxxxxx  # could be a real serial number
/sys/class/dmi/id/chassis_vendor:Default string
/sys/class/dmi/id/chassis_asset_tag:Default string
/sys/class/dmi/id/ec_firmware_release:1.3
/sys/class/dmi/id/power/runtime_active_time:0
/sys/class/dmi/id/power/runtime_status:unsupported
/sys/class/dmi/id/power/runtime_suspended_time:0
/sys/class/dmi/id/power/control:auto
/sys/class/dmi/id/bios_version:R6G07
/sys/class/dmi/id/bios_release:5.19
/sys/class/dmi/id/board_vendor:Default string
/sys/class/dmi/id/chassis_version:Default string
/sys/class/dmi/id/product_sku:Default string
/sys/class/dmi/id/chassis_type:3
/sys/class/dmi/id/chassis_serial:Default string
/sys/class/dmi/id/product_family:Default string
/sys/class/dmi/id/product_uuid:03000200-0400-0500-0006-000700080009
/sys/class/dmi/id/bios_vendor:American Megatrends International, LLC.
/sys/class/dmi/id/board_asset_tag:Default string
/sys/class/dmi/id/board_version:Default string
/sys/class/dmi/id/modalias:dmi:bvnAmericanMegatrendsInternational,LLC.:bvrR6G07:bd08/05/2022:br5.19:efr1.3:svn:pn:pvr:rvnDefaultstring:rnDefaultstring:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:
/sys/class/dmi/id/board_name:Default string

Probably a "crappy DMI Info Table" is not so rare. 
Even the product_uuid has a default value, used in many cheap boards.

Therefore, alsa-lib (and other system libraries) should be able to deal with it (as before), using default or fallback configurations.

My system is a Geekom Mini IT11 Mini-PC which has supported Fedora Linux out of the box (until now).

(In reply to Jaroslav Kysela from comment #3)
> Try this manually (install 1.2.12 and downgrade alsa-ucm only):
> 
>   rpm -e --force --nodeps alsa-ucm
>   rpm -ivh --nodeps alsa-ucm-1.2.11-2.fc40.noarch.rpm

Overwriting packages in /usr is temporarily possible on Atomic Desktops after all.
Sorry, I wasn't aware of it. The following commands are working:

rpm-ostree usroverlay
rpm -Uhv --nodeps --oldpackage alsa-ucm-1.2.11-1.fc40.noarch.rpm

The first command mounts a writable overlay filesystem on /usr which is active only for the remainder of the system boot.
After reboot the original RPM gets restored.

Therefore, I can now confirm that the alsa-ucm configuration from version 1.2.11 works with alsa-lib 1.2.12 on my system.

Thanks to Jaroslav Kysela's comments 3 and 9 I finally did the following steps as my workaround to rectify the reported problem without downgrading or overriding Silverblue packages permanently:

###
# Install/Downgrade temporarily (until next reboot) alsa-ucm-1.2.11:
wget https://kojipkgs.fedoraproject.org//packages/alsa-lib/1.2.11/2.fc40/noarch/alsa-ucm-1.2.11-2.fc40.noarch.rpm
sudo rpm-ostree usroverlay
sudo rpm -Uhv --nodeps --oldpackage alsa-ucm-1.2.11-2.fc40.noarch.rpm

# Copy alsa-ucm config to my home directory:
mkdir -p ~/.config/alsa/ucm2/
rsync -avz /usr/share/alsa/ucm2/ ~/.config/alsa/ucm2/

# Set environment variable ALSA_CONFIG_UCM2 such that it's evaluated by Wayland and gnome-session:
mkdir -p ~/.config/environment.d
cat ~/.config/environment.d/alsa.conf << END
ALSA_CONFIG_UCM2=$HOME/.config/alsa/ucm2
END

systemctl reboot
###

This workaround works only for one user. But I want to keep the base OS clean.
Hope this helps other Silverblue users who may run into the same problem (until it is fixed upstream).

This message is a reminder that Fedora Linux 40 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '40'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 40 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

The problem has disappeared in Fedora Silverblue 42.
I assume, it has been fixed upstream.

My workaround, described in comment 14, worked in Fedora 40 and 41 as well.

Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13.

Fedora Linux 40 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.