I have a machine with the hardware in the title. I am getting no sound off the motherboard (Realtek ALC 887). It seems openSuSE wants to use the HDMI sound from the integrated GPU in the CPU. I have tried Leap 15.5 and Tumbleweed. The following (from Tumbleweed) seems to show that the Realtek is not detected or ignored:
First thing that comes to mind is that the snd_hda_intel kernel module needs a specific model option to recognize your hw (ASUS have an history of unique audio setups…)
Try this page and search for “asus”, there are 48 models listed and maybe one sounds familiar to you.
Or look for “ALC88x” and see if anything familiar is to be found there.
There are some things there that are perhaps pertinent to the problem, in particular the descriptions of the back panel jacks on asus-mobo as a:6stack-digout 6-jack with a SPDIF outwhich is exactly what is on the mobo. There is also asus-mobo Pin configs for ASUS mobo with 5.1/SPDIF out
However, I don’t understand what I’m looking at. I have not read all the documentation. Do these short phrases serve as arguments in the boot loader kernel parameters section?
To test those options you can add to the kernel command line something like:
snd-hda-intel.model=6stack-digout
or
snd-hda-intel.model=asus-mobo
(just press “E” at the grub boot menu and look for the line beginning with linuxefi).
Since your mobo provides two sound “cards”, you may have to add a comma to skip configuration of the HDMI “card” and address the ALC887, like in:
snd-hda-intel.model=,6stack-digout
When you find a working config, you may permanently add that to the kernel boot parameters (you may use YaST Bootloader) or add a config file to modprobe, say /etc/modprobe.d/50-asus-mobo-hda-fix.conf with a line reading:
I spent some time yesterday trying every combination possible of those 2 parameters, both in the yast bootloader kernel parameters section and by adding a file containing options in /etc/modprobe.d . No change so far. In your above post there are
snd-hda-intel.model=(parameter) and snd-hda-intel model=(parameter) .
I assume the latter is the correct one? I tried both anyway.
That was one of the first things I checked. The only entry is for the Realtek HD audio controller, a simple Enable / Disable choice. It has been enabled throughout all of this.
This is the problem (no codecs found!). Now things get a bit messy.
Your last test was apparently done in Leap 15.5. Even if many new features are backported to the 5.14 kernel by SUSE, it is best to do further tests on Tumbleweed updated to the latest kernel (6.8.9 at the moment) to be sure of using the latest drivers and avoid confusion.
The “6stack-digout” option is reported for the ALC880. I don’t know what are the differences between the ALC880 and the ALC887, but generally speaking options for one model might not work for another.
Maybe look at the options reported for ALC88x/… for something relevant.
Also, seeing no output from dmesg means something basic is wrong with that configuration file (and of course you get no sound if you see no snd-hda… in dmesg).
The “asus-mobo” option is for a completely different codec ( STAC92HD73*) so no surprise that it doesn’t work.
On a side note, are you sure that the mobo is equipped with an ALC887? We have no confirmation so far from system output.
Can you post the result of:
sudo lsmod |grep snd
if (as is likely) snd_hda_codec_realtek doesn’t show up, can you try:
Yes, it is Leap 15.5. I reinstalled Leap15.5. I couldn’t live with Tumbleweed. Chromium was constantly generating “Ah,Snap!” errors and the filesystem didn’t make me a member of the “Users” group. All my files on my boot drive were owner $USER and group $USER, which was different from all my data files (2TB worth) on a non-boot drive. Confusing. Among other less important things.
I know it would be best to test on Tumbleweed because of the kernel version, and the use of Pipewire (exclusively?) for sound.
I will continue to look over the HDA sections on kernel.org. I realized there were basic errors by looking at /var/log/messages:
modprobe[705]: libkmod: kmod_config_parse: /etc/modprobe.d/50-asus-mobo-hda-fix.conf line 1: ignoring bad line starting with 'options=snd-hda-intel'
That is repeated throughout /var/log/messages many times, one for each reboot presumably.
Good! One less thing to worry about = 1/2 the work and reboots.
Direct quote from the mobo manual:
PRIME B550-PLUS specifications summary
Audio
Realtek ALC 887 7.1-Channel High Definition Audio CODEC
Supports Jack detection, Multi-streaming, Front Panel Jack-retasking
Supports up to 24-Bit/192 kHz playback
OK, we must trust ASUS for the ALC887 and keep Leap 15.5 for further testing.
“options=…” is wrong, but apparently you changed to the correct “options snd-hda-intel …” afterwards?
As long as no Realtek module shows up I doubt that fiddling with “model=…” options does anything, so after:
does anything change in:
dmesg | grep snd_hda
aplay -l
inxi -Axx
and yes, the last file is the long-lost Realtek driver.
On a side note I found the following kernel bug that might be somewhat related, just for future reference: https://bugzilla.kernel.org/show_bug.cgi?id=211555#c7
So somewhere between detection of the ALC887 and actually booting to a running system, the ALC887 is lost. Which is presumably due to a missing options= line in the information modprobe gives to the kernel.
Something to bear in mind.
On a side note, modprobe passes .zst archives to the kernel? Extraction happens on the fly? Thus slowing down the boot process? After extraction:
Yes, you should find all of them with plain “sudo lsmod”.
Apparently that is part of the problem: the ALC887 does not “ask” the kernel to load the snd_hda_codec_realtek module and even loading it manually doesn’t cause it to connect to the ALC887.
I wonder if the ALC887 is being detected at all, so it is likely not “lost” during boot but simply not detected.
Please be aware that “options=” is wrong, no “=” sign should be used either on the kernel command line or a modprobe.d config file.
Yes, external kernel modules are compressed, forget about it.
If no HW/sound guru steps in with better ideas, maybe filing a bug report at bugzilla.opensuse.org is the way to reach for kernel/hda developers.
I worry about gaffes like that if I’m going to file a bug report.
It’s strange. All of this hardware has been around for a couple of years or more, so I did not anticipate a problem of this magnitude. Has no one ever put an AMD 5700G on an Asus Prime B550-Plus mobo and installed Linux?
Incidentally, I had a spare SATA slot and SSD, so I did a quick install of Linux Mint. Exactly the same problem occurs, including the output of aplay -l, inxi -Axx and dmesg | grep snd_hda.
Hints at a kernel problem, not an openSUSE specific one. We are lucky to have a kernel / sound system developer at SUSE, so a bug report at bugzilla.opensuse.org should attract his attention
The easy part is adding “snd_hda_intel.probe_mask=,0x101” (without quotes and mind the comma) to the kernel command line and boot (just press “E” at the boot screen, adding permanently is not needed until you find out what works).
Repeat with the other codes through 0x180 until you find one that works (if any).
To install kernels from tiwai: repo find the .rpm file, copy the URL and use in zypper, as an example for the 5.14 kernel:
