I suspect a combination. My experience is if a sound card configuration has been removed via YaST, subsequently after a reboot the sound card can be seen again in YaST for editing/configuring. I suspect by installing sof_firmware you were able to remove the ‘dmesg’ errors. … It does thou read that both of those activities were not enough to restore your sound.
I am interested to learn if the grub entry change helped, and also if the ‘aplay’ command I suggested to try yielded any sound.
I am reviewing again the alsa-info.sh script output that you provided. I note this:
!!Sound Servers on this system
!!----------------------------
PipeWire:
Installed - Yes (/usr/bin/pipewire)
Running - Yes
No sound servers found.
We have guests visiting our place at present, and I am not able to access my desktop PC that has Tumbleweed running, but I ask myself, is that normal? There is no mention of ‘pulse audio’ and the script states ‘no sound servers found’. I ask myself, if that is an issue?
Can one of the other openSUSE users monitoring this thread, who have Tumbleweed running, advise if that is normal behaviour? (ie no pulse audio mentioned and ‘no sound servers found’)?
Yes, that is normal output for those using pipewire. (I’m using openSUSE Leap 15.4 with KDE and am also using pipewire.)
The grub flag didn’t change anything noticeable, and the aplay line says it plays, but I don’t hear it on the speakers. I can hear it if I plug the headphones.
What if you start the sound-extra
sudo systemctl start sound-extra.service
You can also do it via yast2 sevices manager
I doubt that will help. This is a low-level audio (firmware, kernel, or hardware related) issue.
When nothing helps me, I try any thing about sound 
According to sevices manager it is " Load extra kernel module for sound stuff"
So what are this extra modules?
Typically, if you can hear sound with headphones, but not with speakers, it is one of two problems:
your mixer or the piperwire equivalent (?) of pulse audio volume control is blocking your audio to your speakers, … or
there is an issue with the kernel with your hardware.
I still can’t access my Tumbleweed PC (to refresh my memory) due to guests using the room where that PC is located, so unfortunately I can’t bring myself up to date wrt pipewire to offer suggestions - but there (pipewire) is where I would focus initially if it were me (assuming mixer setup ok).
If alsa can’t produce audible sound to the speakers, then pipewire (high-level media server) won’t either.
IMHO an openSUSE bug report is required.
Do we know yet its an alsa level issue? As noted, I am not familiar with pipewire on Tumbleweed, but for older LEAP versions a combination of pipe-wire/pulse audio still used pavucontrol, where one could send audio (from a multimedia app) to either speaker or headphones, … and I know of times when audio was not appropriately directed to speakers (but was sent to headphones) with this pulse/pipewire combination.
Is there no equivalent in pipewire, nor any possibility with pipewire to send audio to headphones but not send to speaker (similar to the pulse/pipewire combination where it is entirely possible due to a misconfiguration and not a kernel issue)? I would test this if I could access my Tumbleweed installation PC, but I don’t have access at present.
I’m not saying its not the kernel - but because of my lack of pipewire experience I am not yet certain it is the kernel at fault, given what I have seen can happen with the pulse-pipewire combination. Surely there must be a way to check that? (or was it already in this thread and I missed such … and if so, my apologies for wasting time of those supporting the thread).
Do we know yet its an alsa level issue? As noted, I am not familiar with pipewire on Tumbleweed, but for older LEAP versions a combination of pipe-wire/pulse audio still used pavucontrol, where one could send audio (from a multimedia app) to either speaker or headphones, … and I know of times when audio was not appropriately directed to speakers (but was sent to headphones) with this pulse/pipewire combination.
Is there no equivalent in pipewire, nor any possibility with pipewire to send audio to headphones but not send to speaker (similar to the pulse/pipewire combination where it is entirely possible due to a misconfiguration and not a kernel issue)? I would test this if I could access my Tumbleweed installation PC, but I don’t have access at present.
Take pulseaudio and pipewire out of the equation for a moment. When alsa commands such as aplay can’t play to the speakers, then we can focus our attention on this layer (or the hardware).
If pipewire-pulse is active, this provides some compatibility with pulseaudio client applications, so that one can still use pavucontrol and paplay commands if desired. There is also pipewire-tools which provides commands such as pw-play…
https://en.opensuse.org/openSUSE:Pipewire#Tools
However, aplay should be able to direct sound to any available device for a given sound card, and so far the OP claims no working sound via the internal speakers.
Take pulseaudio and pipewire out of the equation for a moment. When alsa commands such as aplay can’t play to the speakers, then we can focus our attention on this layer (or the hardware).
Nominally I would say yes … however not always (based on my experience). I recall with some pulseaudio system apps in place, my recollection is was possible that even ‘aplay’ could end up routing audio through pulse, dependent on one’s PC’s linux install configuration. Hence often I would recommend running aplay with pasuspender … My knowledge of pipewire is not sufficient to assess if the same is true, which is why I raise this possibility.
But if known this is impossible in pipewire then I will defer to the updated knowledge.
I’ve tested with and without pipewire active. I’m able to play audio using aplay in both situations (as expected). I can also play via pipwire using…
pw-play /usr/share/sounds/alsa/test.wav@cantfind: Please try running the following without the head phones plugged in…
sudo alsactl initthen do
aplay -D plughw:0,0 /usr/share/sounds/alsa/test.wavReturning to your alsa-info.sh output, I note that your notebook is a ASUS ZenBook UX303UA. I’ve found a couple of threads that describe similar non-functional internal speakers with ASUS laptops. They are different models, but both talk about specifying ‘model=asus-zenbook’ (as a module option) successfully. It might be worth a shot…
Tried it, I got in return for the first line the following:
Found hardware: "HDA-Intel" "Conexant CX20751/2" "HDA:14f1510f,1043159f,00100100 HDA:80862809,80860101,00100000" "0x1043" "0x1b1d"
Hardware is initialized using a generic method
and for the second line:
Playing WAVE '/usr/share/sounds/alsa/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
But still no sound.
Also tried adding to /etc/modprob.d/50-yast.conf the line
options snd-hda-intel model=asus-zenbook
(it’s the only thing in that fie, and the only .conf file in that directory).
Still nothing.
Then it is time to report it as a bug.
https://en.opensuse.org/openSUSE:Submitting_bug_reports
https://bugzilla.opensuse.org/index.cgi