That’s why I asked the OP about whether such a key existed. 
Well I had to install alsa (and inxi) for giving a few of your commands ;). And as alsa doesn’t get default installed anymore on GNOME…
I think you mean alsa-utils. The main ALSA packages should already be installed, as working audio depends on it. For reference, I have
~> zypper se -si alsa
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------------+---------+-------------------+--------+----------------
i | alsa | package | 1.2.14-160000.3.1 | x86_64 | repo-oss (16.0)
i | alsa-oss | package | 1.1.8-bp160.1.12 | x86_64 | repo-oss (16.0)
i | alsa-plugins | package | 1.2.12-bp160.1.13 | x86_64 | repo-oss (16.0)
i | alsa-plugins-speexrate | package | 1.2.12-bp160.1.13 | x86_64 | repo-oss (16.0)
i | alsa-plugins-upmix | package | 1.2.12-bp160.1.13 | x86_64 | repo-oss (16.0)
i | alsa-ucm-conf | package | 1.2.14-160000.2.2 | noarch | repo-oss (16.0)
i+ | alsa-utils | package | 1.2.14-160000.2.2 | x86_64 | repo-oss (16.0)
i | pipewire-alsa | package | 1.4.6-160000.3.1 | x86_64 | repo-oss (16.0)
Note: For an extended search including not yet activated remote resources please use 'zypper
search-packages'.
Nope, alsa is not installed at all.
You wouldn’t have working sound if that was really the case. You would need at least the alsa package for normal ALSA userspace audio support. The kernel provides the ALSA drivers, while the alsa package provides the userspace libraries that PipeWire and other applications use to access them. The alsa-utils is separate and just provides tools such as arecord, aplay and alsamixer.
It’s likely that your hardware setup also required alsa-ucm-conf as the UCM configuration tells ALSA/PipeWire how a particular sound card’s hardware should be presented (inputs, outputs, routes, profiles, etc).
I can guarantee you that alsa wasn’t preinstalled. I was also quite astonished when I first installed it today. (tbf I installed alsa-utils, and that pulled in alsa)
Well, that would be bug report material, and if the alsa package containing libasound really wasn’t installed, PipeWire’s ALSA backend couldn’t normally access ALSA devices at all. No sound.
Correction:
~> rpm -qf /usr/lib64/libasound.so.2
libasound2-1.2.14-160000.3.1.x86_64
This needs to be present, and pipewire-alsa.
will do so then
Please show the current installed packages…
zypper se -si alsa asound
Just to clarify: No bug report needed as pipewire-alsa only depends on libasound2 (not the alsa userspace package as I had thought).
~> rpm -q --requires pipewire-alsa | grep -E 'alsa|asound'
config(pipewire-alsa) = 1.4.6-160000.3.1
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)
~> ldd /usr/lib64/spa-0.2/alsa/libspa-alsa.so | grep asound
libasound.so.2 => /lib64/libasound.so.2 (0x00007fcd3e569000)
but maybe you did need alsa-ucm-conf for mic input support?
hm, that could be the case. I will try it out later
1 Like
yes this was actually the package which fixes it. Nice
1 Like
Did you perhaps in the Agama installer deselect the Multimedia pattern? Asking this because that is what I did with today’s Leap 16.1 install and … it has no alsa, except pipewire-alsa …
1 Like
Interesting Gertjan. I assume that you still have libasound2 and pipewire-alsa installed at least?
Yup, those two are installed.
Thanks for confirming…that makes sense as libasound2 is used by PipeWire itself via its ALSA SPA plugins (pipewire-spa-plugins), while pipewire-alsa provides the ALSA compatibility layer for applications using ALSA.
I hadn’t relaised that the alsa user-space package itself is redundant, unless alsa-utils is wanted. I’ve always used the CLI utilities the latter provides to verify that the ALSA layer working as expected. 
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.