Again no sound after today’s (2023-01-16) update

No changes to the system except the daily tumbleweed update, but after the restart, I can not get any sound.

It’s an AMD Radeon sound card connected via HDMI to my AV receiver.

I remember ~1/2 to a year ago a similar problem happened, and was then resolved after an update a few days later. I assume something similar happened again.

Something special with my system:

two AMD Radeon graphics cards, one with two DVI outputs, the other one with HDMI output, that is connected to the AV receiver.

In the sound setup, there’s no way of distinguishing the two cards. I already made a feature request to show the PCI ID/Slot ID in yast sound

sound

but until today no changes…

By default, sound is normally sent to sound-card-0 (at least that was the way it used to be in openSUSE). Is there any chance the sound from your multimedia applications is being sent to the wrong device?

I am a bit rusty, but in the past it was possible via a hand edit to a configuration file to specify which sound-device would be assigned to which sound card.

Also, even if one did not do this, it was possible via ‘pavucontrol’ to specify which sound device an application would use for sending sound. I haven’t tested this in Tumbleweed (yet) myself, but I suspect it is still possible by some method.

I hope to have access again to my Tumbleweed PC in the near future, and thus able to test this.
. If I do, and if I relearn how, and if this issue still not solved, I will post.

I managed to jump on my Tumbleweed PC (its been months since last used) and I did a “zypper dup” to obtain the latest (?) version. My PC has 3 audio devices, two separate devices each of which has its own “snd_hda_intel” alsa module instance running and one is a USB audio (webcam for recording only).

I note according to the ‘alsa-info’ script that piperwire is running, with no other ‘sound servers’ found. I haven’t tested redirecting sound (just yet) but I note my headset audio works fine (I normally only use a headset so not to bother my wife).

I also note that the pulse audio volume control app (pavucontrol) that in the past I used with pulse audio, is still running, and it gives me a selection of input audio devices that I can assign to different devices.

Did you try to see if ‘pavucontrol’ gives you the ability to direct sound from any given multimedia application to a different sound device?

Did you try running the alsa-info diagnostic script to see if it gives you hints as to your sound issue?

I have to read up on openSUSE:Pipewire - openSUSE Wiki before I can offer much more guidance in regards to pipewire. I see from that article that openSUSE pipewire also uses ‘wireplumber’ as the multimedia framework to be an audio (and video) server … so its possible if you can’t redirect sound with ‘pavucontrol’ it can be done with that - but I need to read up more on this before I can say if that is indeed the case.

Likely someone more up to date than myself on this, has already been down this path of research, and they could chime in here.

Host erlangen has two sound cards:

erlangen:~ # inxi -aA
Audio:
  Device-1: AMD Baffin HDMI/DP Audio [Radeon RX 550 640SP / 560/560X]
    vendor: Sapphire driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s
    lanes: 8 bus-ID: 2b:00.1 chip-ID: 1002:aae0 class-ID: 0403
  Device-2: AMD Starship/Matisse HD Audio vendor: Micro-Star MSI
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 2d:00.4 chip-ID: 1022:1487 class-ID: 0403
  Sound API: ALSA v: k5.18.11-1-default running: yes
  Sound Server-1: PulseAudio v: 16.1 running: no
  Sound Server-2: PipeWire v: 0.3.64 running: yes
erlangen:~ # 
erlangen:~ # systemctl list-units --quiet '*sound*'
  sys-devices-pci0000:00-0000:00:03.1-0000:2b:00.1-sound-card0-controlC0.device loaded active plugged /sys/devices/pci0000:00/0000:00:03.1/0000:2b:00.1/sound/card0/controlC0
  sys-devices-pci0000:00-0000:00:08.1-0000:2d:00.4-sound-card1-controlC1.device loaded active plugged /sys/devices/pci0000:00/0000:00:08.1/0000:2d:00.4/sound/card1/controlC1
  sound.target                                                                  loaded active active  Sound Card
erlangen:~ # 

Both are active and working as intended:

erlangen:~ # journalctl -b -g snd
Jan 16 18:55:01 erlangen kernel: ata5.00: Features: NCQ-sndrcv
Jan 16 18:55:03 erlangen kernel: snd_hda_intel 0000:2b:00.1: enabling device (0000 -> 0002)
Jan 16 18:55:03 erlangen kernel: snd_hda_intel 0000:2b:00.1: Handle vga_switcheroo audio client
Jan 16 18:55:03 erlangen kernel: snd_hda_intel 0000:2b:00.1: Force to non-snoop mode
Jan 16 18:55:03 erlangen kernel: snd_hda_intel 0000:2d:00.4: enabling device (0000 -> 0002)
Jan 16 18:55:03 erlangen kernel: snd_hda_intel 0000:2b:00.1: bound 0000:2b:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC897: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:    inputs:
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:      Front Mic=0x19
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:      Rear Mic=0x18
Jan 16 18:55:03 erlangen kernel: snd_hda_codec_realtek hdaudioC1D0:      Line=0x1a
Jan 17 04:56:50 erlangen kernel: ata5.00: Features: NCQ-sndrcv
Jan 18 06:03:50 erlangen kernel: ata5.00: Features: NCQ-sndrcv
erlangen:~ # 

In the past sound stopped working once in a while after upgrading Tumbleweed, presumably due to interference from “yast2 sound”. However “yast2 sound” now is gone on erlangen. No more issues with sound encountered since a long time.

Showing the output of the above commands running on your machine may help in investigating your issues.

I am still researching this, as pipewire is new to me.

I note there is an application called " helvum " ( https://gitlab.freedesktop.org/pipewire/helvum ) which is also in the openSUSE tumbleweed repository, that allows one to redirect sound, but its not for the fainthearted and I have not used it yet , so I don’t recommend its use initially (at least not until I learn more).

A way that may work to reverse the order of sound devices, is a very old method, where one creates a text file /etc/modprobe.d/50-sound.conf … and puts in that file this line:

options snd-hda-intel index=1,0

that should reverse the order of sound devices. One can also use this instead:

options snd-hda-intel index=0,1

which I think should give the default order of devices.

I can’t confirm if that works in Tumbleweed (as of yet) as I still have not tried it myself.

However BEFORE doing any of these “exotic” investigations/fixes, please triple check that your are not experiencing something as simple as a mixer misconfiguration.

Qpwgraph is better in my opinion it is also in the tumbleweed repository, it is I am using. Qpwgraph can simultaneously output sound from more than 2 sources. I tested this with 3 to output to HDMI, builtin audio and bluetooth and all worked simultaneously.

Another way for this when you only want to get a sound from a specific source is turn off the other sound card in pavucontrol.

Interesting suggestion of Qpwgraph. I will have to play with it for a while to better understand. Here is the output on my desktop PC (with Tumbleweed) which I currently have configured for only playing to plugin headset (in this example Chrome browser playing a youtube video to my plugin headphones):

and here is the same Chrome browser playing a youtube video to my plugin headphones, but in this case I also have ‘pavucontrol’ running in the background:

I can see this will take me time to fully understand. I had to re-arrange things to make the presentation more ‘presentable’, but I may have not displayed it as well as I could.

Most interesting.

It’s just connecting the nodes from source to where you want to output the sound.


I am playing an audio using audacious and audacious is connected to the HDMI and builtin audio as you can see in my screenshot.

My apologies, I made a mistake, I uploaded the wrong image. Here is what I wanted to show…


Audacious is supplying the sound to builtin audio and HDMI simultaneously.

The node are similar to when connecting in blender cycles :wink:

That’s the output on my system:

horus:/home/alex # systemctl list-units --quiet '*sound*'
  sys-devices-pci0000:00-0000:00:01.2-0000:02:00.2-0000:03:00.0-0000:04:00.1-sound-card0-controlC0.device loaded active plugged /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.2/0000:03:00.0/0000:04:00.1/sound/card0/controlC0
  sys-devices-pci0000:00-0000:00:03.1-0000:0a:00.1-sound-card1-controlC1.device                           loaded active plugged /sys/devices/pci0000:00/0000:00:03.1/0000:0a:00.1/sound/card1/controlC1                          
  sound.target                                                                                            loaded active active  Sound Card
horus:/home/alex # journalctl -b -g snd
Jan 18 20:03:46 horus kernel: ata7.00: Features: NCQ-sndrcv
Jan 18 20:03:46 horus kernel: ata10.00: Features: NCQ-sndrcv
Jan 18 20:03:46 horus kernel: ata9.00: Features: NCQ-sndrcv
Jan 18 20:03:46 horus kernel: ata4.00: Features: NCQ-sndrcv
Jan 18 20:03:50 horus kernel: snd_hda_intel 0000:04:00.1: Handle vga_switcheroo audio client
Jan 18 20:03:50 horus kernel: snd_hda_intel 0000:0a:00.1: Handle vga_switcheroo audio client


Ok, after a few restarts (and today’s updates), sound now works again. Not sure what was wrong yesterday. ¯_(o.O)_/¯

Thanks for the update.