Updated recently - Soundblaster card no longer available in GUI

English Install/Boot/Login
21

…I updated (zypper dup) the system 1-2 hours ago and rebooted, no changes.

I have another TW KDE with

02:00.0 Multimedia audio controller: Creative Labs EMU10k2/CA0100/CA0102/CA10200 [Sound Blaster Audigy Series] (rev 04)

that is just doing fine (audio) with pipewire. Sigh…

22

I understand.

Still, your sound card is not detected by aplay, arecord, nor amixer. Why would pipewire interfere with that? When pipewire has an issue, does pipewire typically break things at the alsa level?

Further, I note the kernel module " snd_ctxfi " is loaded according to the diagnostic script you ran. Hence I speculate that another possibility is that there could be a problem with that kernel module? … That’s speculation on my part.

When you conducted the pipewire update, did you also update the kernel ? If so, maybe there is a kernel issue, with a regression? My speculation.

23

I installed the plugins 32bit version in addition, reboot, no audio card…

Alsa script output now:

https://paste.opensuse.org/b3c2eb82

24

Now I installed again this pipewire trash on top (newest from packman). No audio.

25

Pipewire is getting the blame. Are you using pipewire or pulseaudio?
Sorry I didn’t read the whole thread. If the sound card is not detected then most
probable cause is a firmware problem. Good to check the sound card physical
connection also.

26

Audio was just working fine before the pipewire-media-session troubles. What I’m currently using? No idea, audio in linux is a mistery to me. It simply has to work and it did on this hardware (and it does now when booting Leap 15.3).

27

why did you install plugins 32bit ?? Blindly installing apps is not imho a good way to solve an issue, and it risks making things worse - or at least that is my experience.

From that script I note the alsa modules are loaded …


!!Loaded ALSA modules
!!-------------------
snd_ctxfi (card 0)
snd_hda_intel (card 1)
cx23885 (card 2)

yet despite being loaded, look at this:


!!Aplay/Arecord output
!!--------------------
 
APLAY
 
aplay: device_list:274: no soundcards found...
 
ARECORD
 
arecord: device_list:274: no soundcards found...
 
!!Amixer output
!!-------------
 
!!-------Mixer controls for card XFi
 
Invalid card number 'XFi'.
Invalid card number 'XFi'.
 
!!-------Mixer controls for card HDMI
 
Invalid card number 'HDMI'.
Invalid card number 'HDMI'.
 
!!-------Mixer controls for card CX23885
 
Invalid card number 'CX23885'.
Invalid card number 'CX23885'.

again - I know you think this is pipewire, but I am NOT convinced of that. If this is pipewire, breaking low level alsa aspects is a surprise to me, then hopefully someone will teach me why pipewire will break things deep down at the alsa level ??? , as when I see the amixer, aplay and arecord broke, that to the best of my limited knowledge is NOT at pipewire level. Ergo from what I see, there is more to this issue than pipewire.

You say this works in LEAP-15.3. How about running the script there, so we can compare the script of Tumbleweed where it fails, and LEAP-15.3 where it works?

Honestly, if I had to bet - I would bet on a kernel issue - either or a regression or on firmware missing (although with the kernel module loading and the dmesg not mentioning a firmware issue, I suspect it is the kernel itself). And if this is a kernel regression, then the QUICKEST way to solve is a bug report to obtain the support of the excellent openSUSE sound packagers (at least one of whom is an alsa sound driver developer).

Please, can you tell us WHEN you updated the kernel last?

28

Last zypper dup was yesterday, iirc kernel update was included as reboot was requested in the end.

32bit was a suggestion above.

29

Thanks. I still believe this could be a kernel regression, as I do not understand why a pipewire issue would break amixer, aplay and arecord. Again, I would be most interested to learn if am wrong here.

I also suspect that when you updated pipewire, at around the same time you likely also updated the kernel.

With respect I fail to see the logic of that addition of a 32-bit package. I don’t understand such a suggestion as to the 32-bit … (although I do appreciate that user’s approach - as such works for them - but I note they likely have very different hardware).

My recommendation here, if you obtain no suggestions that work, would be to write a bug report on the TUMBLEWEED Kernel, noting this worked in an earlier kernel.

You could also write the bug report instead against pipewire - but I don’t think that is the correct approach. I suspect (albeit I would be happy to be proven wrong) that when you attach the output of the alsa-info.sh script to your bug report, those looking at the bug report will see the issue with amixer, aplay and arecord, and possibly come to the same view as myself. If I am correct, they would then possibly re-assign the bug report to the kernel, but that could take a couple of weeks ?? or so for such to be moved and then seen/actioned.

Apologies for my skepticism (as to this being due to a pipewire update), and I hope you come up with a fix.
.

30

Thanks for taking time to help! Not your fault if it doesn’t work. Enjoy your time at the beach… :wink:

31

I agree. The alsa-info.sh diagnostic output clearly reports a problem with the alsa layer.

32

I wanted to follow-up with a (partial) solution of the mystery. The problem occured after this pipwire update, when I was using the machine physically sitting in front of it. So it was real. But later, during debugging, I was using the machine via VNC. And one of the steps I performed ffinally solved the problem, as now (sitting physically in front of them machine again), audio is working again.

But via VNC there is apparently no access to the audio devices. Security? So that one can’t start audio remotely? I don’t know. But the problem is solved, although I can’t say which of the steps I did was actually the right one… :wink: