Today I updated the software on my Fedora 36 and now there is no sound. I used Gnome Software to update. Neither VLC nor Firefox produces sound. In Settings -> Sound -> Output there are two values under Output Device, both saying HDMI/DisplayPort - Built-in Audio. No difference between them, when using the Test functionality both stay silent.
Any advice?
On Fri, 16 Sep 2022 16:14:04 +0200 andreas.fournier@runbox.com wrote:
Today I updated the software on my Fedora 36 and now there is no sound. I used Gnome Software to update. Neither VLC nor Firefox produces sound. In Settings -> Sound -> Output there are two values under Output Device, both saying HDMI/DisplayPort - Built-in Audio. No difference between them, when using the Test functionality both stay silent.
Any advice?
What updated? That might give a hint of what is causing the issue.
How many sound devices do you have? The two you mention sound like they are from the video hardware. Is there another device built into the MB?
Look at the output of lspci to see if all the sound devices are there.
Look at the output of aplay -l to see if alsa is aware of all your devices.
If alsa knows about your device, does aplay -D [device name] [some.wav] produce sound output?
Check in the journal with journalctl -b0 to see if there are errors during sound discovery.
Someone else had a similar problem recently on this list, and it was suggested they try an older kernel. You could try that. Unforunately, they never posted back about the resolution of their problem.
It might be that some of the updates you got need a reboot in order to actually be instantiated, so just a reboot might fix the sound discovery process.
On Fri, 2022-09-16 at 08:00 -0700, stan via users wrote:
On Fri, 16 Sep 2022 16:14:04 +0200 andreas.fournier@runbox.com wrote:
Today I updated the software on my Fedora 36 and now there is no sound. I used Gnome Software to update. Neither VLC nor Firefox produces sound. In Settings -> Sound -> Output there are two values under Output Device, both saying HDMI/DisplayPort - Built-in Audio. No difference between them, when using the Test functionality both stay silent.
Any advice?
What updated? That might give a hint of what is causing the issue.
How many sound devices do you have? The two you mention sound like they are from the video hardware. Is there another device built into the MB?
Look at the output of lspci to see if all the sound devices are there.
Look at the output of aplay -l to see if alsa is aware of all your devices.
If alsa knows about your device, does aplay -D [device name] [some.wav] produce sound output?
Check in the journal with journalctl -b0 to see if there are errors during sound discovery.
Thanks for the tips.
I tried to reboot to previous kernel, that didn't change anything.
The list of updated software packages are at the end.
lspci gave two lines with Audio device 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 0a) 00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
aplay -l gave the following **** List of PLAYBACK Hardware Devices **** card 1: HDMI [HDA Intel HDMI], device 3: HDMI 0 [DELL U3415W] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA Intel HDMI], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PCH [HDA Intel PCH], device 3: ALC892 Digital [ALC892 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0
I tried to test aplay -D, but I couldn't figure out the matching device name. Any advice?
List of updated software today
linux-firmware-whence libreoffice-data samba-common samba-client-libs libwbclient samba-common-libs samba-libs samba-dc-libs libsmbclient python3-samba-dc samba python3-samba samba-common-tools vim-data libgs ImageMagick-libs ghostscript-tools-fonts ghostscript-tools-printing ghostscript java-11-openjdk-headless java-11-openjdk amd-gpu-firmware intel-gpu-firmware iwlax2xx-firmware iwl7260-firmware nvidia-gpu-firmware vim-filesystem vim-common system-config-printer-libs python3-regex open-vm-tools libreoffice-ure-common libreoffice-opensymbol-fonts dnf-data python3-dnf dnf python3-dnf-plugins-core python3-dnf-plugins-extras-common autocorr-en libreoffice-help-en libreoffice-gtk3 libreoffice-ure libreoffice-x11 libreoffice-core libreoffice-langpack-en libreoffice-pyuno libreoffice-pdfimport libreoffice-graphicfilter libreoffice-calc libreoffice-writer libreoffice-ogltrans libreoffice-impress libreoffice-xsltfilter libreoffice-filters libreoffice-emailmerge libreoffice-base libreoffice-draw libreoffice-math python3-dnf-plugin-system-upgrade linux-firmware-whence libreoffice-data samba-common samba-client-libs libwbclient samba-common-libs samba-libs samba-dc-libs libsmbclient python3-samba-dc samba python3-samba samba-common-tools vim-data libgs ImageMagick-libs ghostscript-tools-fonts ghostscript-tools-printing ghostscript java-11-openjdk-headless java-11-openjdk amd-gpu-firmware intel-gpu-firmware iwlax2xx-firmware iwl7260-firmware nvidia-gpu-firmware vim-filesystem vim-common system-config-printer-libs python3-regex open-vm-tools libreoffice-ure-common libreoffice-opensymbol-fonts dnf-data python3-dnf dnf python3-dnf-plugins-core python3-dnf-plugins-extras-common autocorr-en libreoffice-help-en libreoffice-gtk3 libreoffice-ure libreoffice-x11 libreoffice-core libreoffice-langpack-en libreoffice-pyuno libreoffice-pdfimport libreoffice-graphicfilter libreoffice-calc libreoffice-writer libreoffice-ogltrans libreoffice-impress libreoffice-xsltfilter libreoffice-filters libreoffice-emailmerge libreoffice-base libreoffice-draw libreoffice-math python3-dnf-plugin-system-upgrade
On Fri, 2022-09-16 at 20:32 +0200, andreas.fournier@runbox.com wrote:
On Fri, 2022-09-16 at 08:00 -0700, stan via users wrote:
On Fri, 16 Sep 2022 16:14:04 +0200 andreas.fournier@runbox.com wrote:
Today I updated the software on my Fedora 36 and now there is no sound. I used Gnome Software to update. Neither VLC nor Firefox produces sound. In Settings -> Sound -> Output there are two values under Output Device, both saying HDMI/DisplayPort - Built-in Audio. No difference between them, when using the Test functionality both stay silent.
Any advice?
Same problem - I found this
https://www.reddit.com/r/Fedora/comments/xgemxa/f36_no_hdmi_audio/
"The 5.19.8 kernel broke it. 5.19.9 is in testing right now and is meant to fix it."
John
On Sat, 2022-09-17 at 12:03 +0100, ja wrote:
On Fri, 2022-09-16 at 20:32 +0200, andreas.fournier@runbox.com wrote:
On Fri, 2022-09-16 at 08:00 -0700, stan via users wrote:
On Fri, 16 Sep 2022 16:14:04 +0200 andreas.fournier@runbox.com wrote:
Today I updated the software on my Fedora 36 and now there is no sound. I used Gnome Software to update. Neither VLC nor Firefox produces sound. In Settings -> Sound -> Output there are two values under Output Device, both saying HDMI/DisplayPort - Built-in Audio. No difference between them, when using the Test functionality both stay silent.
Any advice?
Same problem - I found this
https://www.reddit.com/r/Fedora/comments/xgemxa/f36_no_hdmi_audio/
"The 5.19.8 kernel broke it. 5.19.9 is in testing right now and is meant to fix it."
Alright, thanks
On Fri, 16 Sep 2022 20:32:29 +0200 andreas.fournier@runbox.com wrote:
I see from the other answer that there was a regression that caused this to happen to you, but I'll give a few answers.
I tried to reboot to previous kernel, that didn't change anything.
The list of updated software packages are at the end.
lspci gave two lines with Audio device 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 0a) 00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
This is the device you want to be default if you want to use analog audio. It is strange that there is no card 0. That is usually the slot that the default audio takes.
aplay -l gave the following **** List of PLAYBACK Hardware Devices **** card 1: HDMI [HDA Intel HDMI], device 3: HDMI 0 [DELL U3415W] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA Intel HDMI], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PCH [HDA Intel PCH], device 3: ALC892 Digital [ALC892 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0
I tried to test aplay -D, but I couldn't figure out the matching device name. Any advice?
aplay -D plughw:2,0 [some wav file] will play analog output on the second card.
List of updated software today
[snipped]
The only things I see in here that might affect sound are the firmware updates.
And if this is a kernel issue, how is it that it didn't take a kernel update to cause it? It was working before the update with the same kernel, why would it stop? Strange.
On Sat, 2022-09-17 at 12:03 +0100, ja wrote:
On Fri, 2022-09-16 at 20:32 +0200, andreas.fournier@runbox.com wrote:
On Fri, 2022-09-16 at 08:00 -0700, stan via users wrote:
On Fri, 16 Sep 2022 16:14:04 +0200 andreas.fournier@runbox.com wrote:
Today I updated the software on my Fedora 36 and now there is no sound. I used Gnome Software to update. Neither VLC nor Firefox produces sound. In Settings -> Sound -> Output there are two values under Output Device, both saying HDMI/DisplayPort - Built-in Audio. No difference between them, when using the Test functionality both stay silent.
Any advice?
Same problem - I found this
https://www.reddit.com/r/Fedora/comments/xgemxa/f36_no_hdmi_audio/
"The 5.19.8 kernel broke it. 5.19.9 is in testing right now and is meant to fix it."
So, I just updated to kernel 5.19.9-200.fc36.x86_64 that was released today. Unfortunately that didn't change anything. Still no sound :(
Makes me think that is wasn't a kernel issue at all, as the software update that originally broke the sound didn't contain a new kernel. But it did contain some firmware updates.
Is it possible to downgrade firmware packages? Or are they oneway?
xgemxa/f36_no_hdmi_audio/
"The 5.19.8 kernel broke it. 5.19.9 is in testing right now and is meant to fix it."
So, I just updated to kernel 5.19.9-200.fc36.x86_64 that was released today. Unfortunately that didn't change anything. Still no sound :(
Makes me think that is wasn't a kernel issue at all, as the software update that originally broke the sound didn't contain a new kernel. But it did contain some firmware updates.
Is it possible to downgrade firmware packages? Or are they oneway? _______________________________________________
I have just done a full update and all now seems OK Tested on brave & vlc.
I have a feeling that the output devices my be different than before but that may just be a bad memory!
I did read somewhere that this may help dnf install pipewire-pulseaudio-0.3.29-1.fc36 reboot ie downgrade from pipewire-pulseaudio-0.3.58-1.fc36.x86_64
Might be worth a try. John
On Sun, 18 Sep 2022 16:10:27 +0200 andreas.fournier@runbox.com wrote:
So, I just updated to kernel 5.19.9-200.fc36.x86_64 that was released today. Unfortunately that didn't change anything. Still no sound :(
Makes me think that is wasn't a kernel issue at all, as the software update that originally broke the sound didn't contain a new kernel. But it did contain some firmware updates.
Is it possible to downgrade firmware packages? Or are they oneway?
Yes, you can go here, https://koji.fedoraproject.org/koji/search?match=glob&type=package&t... and find the firmware package you want to downgrade, here is an example, https://koji.fedoraproject.org/koji/packageinfo?packageID=29969 and then select the package you want to downgrade to. Once you have downloaded it to your system, in the directory where it is saved, run dnf -C downgrade [firmware package name] This will downgrade the package. However, I am not familiar with the program that installs the firmware, and I don't know if it will allow an earlier firmware to install over a later firmware. It should, but I'm not sure. I think it will take a reboot for the downgraded firmware to be used by the kernel.
If it works to restore your sound, you should do two things.
1. Edit /etc/dnf/dnf.conf, or the equivalent on gnome package manager, and put a line with excludepkgs=[name of your firmware package] so it isn't updated again.
2. Open a bugzilla at https://bugzilla.redhat.com/ against the firmware package about the problem so knowledge that the problem exists gets to someone who can fix it.
And if this is a kernel issue, how is it that it didn't take a kernel update to cause it? It was working before the update with the same kernel, why would it stop? Strange.
It may have been a perfect storm of e.g. a previous kernel upgrade which introduced a condition that a later audio or firmware upgrade triggered.
There are a BUNCH of things which can affect audio. A weird combo could have brought some odd issue that caused the problem. It looks like the kernel team is aware of the issue, and I expect it either has been, or will soon be fixed, according to "ja" who posted on this thread.
If not, please file bugzilla reports at https://bugzilla.redhat.com/. See https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/ for details.
Thomas
On Sun, 2022-09-18 at 15:39 +0100, ja wrote:
xgemxa/f36_no_hdmi_audio/
"The 5.19.8 kernel broke it. 5.19.9 is in testing right now and is meant to fix it."
So, I just updated to kernel 5.19.9-200.fc36.x86_64 that was released today. Unfortunately that didn't change anything. Still no sound :(
Makes me think that is wasn't a kernel issue at all, as the software update that originally broke the sound didn't contain a new kernel. But it did contain some firmware updates.
Is it possible to downgrade firmware packages? Or are they oneway? _______________________________________________
I have just done a full update and all now seems OK Tested on brave & vlc.
I have a feeling that the output devices my be different than before but that may just be a bad memory!
I did read somewhere that this may help dnf install pipewire-pulseaudio-0.3.29-1.fc36 reboot ie downgrade from pipewire-pulseaudio-0.3.58-1.fc36.x86_64
Where would I find pipewire-pulseaudio-0.3.29-1.fc36?
What I tried was 'dnf downgrade pipewire' and it downgraded to pipewire-0.3.49-1.fc36 along with some other pipewire-* packages. I rebooted but it didn't change anything.
I think I will try downgrading firmware next.
On Mon, 2022-09-19 at 12:40 +0200, andreas.fournier@runbox.com wrote:
On Sun, 2022-09-18 at 15:39 +0100, ja wrote:
xgemxa/f36_no_hdmi_audio/
"The 5.19.8 kernel broke it. 5.19.9 is in testing right now and is meant to fix it."
So, I just updated to kernel 5.19.9-200.fc36.x86_64 that was released today. Unfortunately that didn't change anything. Still no sound :(
Makes me think that is wasn't a kernel issue at all, as the software update that originally broke the sound didn't contain a new kernel. But it did contain some firmware updates.
Is it possible to downgrade firmware packages? Or are they oneway? _______________________________________________
I have just done a full update and all now seems OK Tested on brave & vlc.
I have a feeling that the output devices my be different than before but that may just be a bad memory!
I did read somewhere that this may help dnf install pipewire-pulseaudio-0.3.29-1.fc36 reboot ie downgrade from pipewire-pulseaudio-0.3.58-1.fc36.x86_64
Where would I find pipewire-pulseaudio-0.3.29-1.fc36?
What I tried was 'dnf downgrade pipewire' and it downgraded to pipewire-0.3.49-1.fc36 along with some other pipewire-* packages. I rebooted but it didn't change anything.
I think I will try downgrading firmware next.
oops ! The suggestion I was referring to was https://www.ericsbinaryworld.com/2022/09/10/warning-bug-in-latest-pipewire-p...
Where it clearly says
dnf install pipewire-pulseaudio-0.3.49-1.fc36 NOT 0.3.29-1 - sorry
As I have my own local repo the rpm and dependencies were picked up from there. dnf recognised it as a downgrade and just did it. Downgrading: pipewire x86_64 0.3.49-1.fc36 local-36-update 39 k pipewire-alsa x86_64 0.3.49-1.fc36 local-36-update 62 k pipewire-gstreamer x86_64 0.3.49-1.fc36 local-36-update 61 k pipewire-libs x86_64 0.3.49-1.fc36 local-36-update 1.6 M pipewire-pulseaudio x86_64 0.3.49-1.fc36 local-36-update 28 k pipewire-utils x86_64 0.3.49-1.fc36 local-36-update 327 k
I repeat that in my case this was not needed, with kernel 5.19.9-200.fc36.x86_64 and pipewire-0.3.58-1.fc36.x86_64 all is well.
John
On Fri, Sep 16, 2022 at 11:01 AM stan via users users@lists.fedoraproject.org wrote:
Someone else had a similar problem recently on this list, and it was suggested they try an older kernel. You could try that. Unforunately, they never posted back about the resolution of their problem.
I am that someone, I think. Apologies for not following up. This is a work-weekday machine and I just got back to the office and today's updates to 5.19.9-100.fc35.x64_64 made no difference. I also tried a Live USB from the F33 days and still no sound. I suspect my issues are dead hardware and not relevant to the other issues going on.
On Mon, 2022-09-19 at 14:44 +0100, ja wrote:
The suggestion I was referring to was https://www.ericsbinaryworld.com/2022/09/10/warning-bug-in-latest-pipewire-p...
Thanks for the link. What I now tried was to first update everything to latest version from repo. Then as root I did a 'dnf install pipewire-pulseaudio-0.3.49-1.fc36' that went fine. Then I did 'systemctl restart pipewire-pulse.service' that gave the following error 'Failed to restart pipewire-pulse.service: Unit pipewire-pulse.service not found.'
I started to look through the log and found following red error produced at the same time I did the commands
systemd: pam_systemd(login:session): Failed to release session: Access denied
and following yellow errors
dbus-broker: Peer :1.286 is being disconnected as it sent a message with an invalid header. dbus-broker: A security policy denied :1.751 to send method call /org/freedesktop/login1:org.freedesktop.login1.Manager.ReleaseSession to org.freedesktop.login1.
Don't you need to start pipewire as the normal user? i.e.
[host@non-root-user]$ systemctl restart pipewire-pulse.service --user
suomi
On 20/09/2022 09.01, andreas.fournier@runbox.com wrote:
On Mon, 2022-09-19 at 14:44 +0100, ja wrote:
The suggestion I was referring to was https://www.ericsbinaryworld.com/2022/09/10/warning-bug-in-latest-pipewire-p...
Thanks for the link. What I now tried was to first update everything to latest version from repo. Then as root I did a 'dnf install pipewire-pulseaudio-0.3.49-1.fc36' that went fine. Then I did 'systemctl restart pipewire-pulse.service' that gave the following error 'Failed to restart pipewire-pulse.service: Unit pipewire-pulse.service not found.'
I started to look through the log and found following red error produced at the same time I did the commands
systemd: pam_systemd(login:session): Failed to release session: Access denied
and following yellow errors
dbus-broker: Peer :1.286 is being disconnected as it sent a message with an invalid header. dbus-broker: A security policy denied :1.751 to send method call /org/freedesktop/login1:org.freedesktop.login1.Manager.ReleaseSession to org.freedesktop.login1.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 2022-09-20 at 10:38 +0200, fedora wrote:
Don't you need to start pipewire as the normal user? i.e.
[host@non-root-user]$ systemctl restart pipewire-pulse.service --user
ah, right. When run as a normal user that command succeeds and in the log I can find
systemd[2290]: Stopping pipewire-pulse.service - PipeWire PulseAudio... systemd[2290]: Stopped pipewire-pulse.service - PipeWire PulseAudio. systemd[2290]: Started pipewire-pulse.service - PipeWire PulseAudio. rtkit-daemon[1231]: Successfully made thread 62005 of process 62005 (/usr/bin/pipewire-pulse) owned by '1000' high priority at nice level - 11.rtkit-daemon[1231]: Successfully made thread 62014 of process 62005 (/usr/bin/pipewire-pulse) owned by '1000' RT at priority 20. juno pipewire-pulse[62013]: 536870912
But still no audio.
Also tried 'aplay -D plughw:2,0 <audio file>'. No audio was produced.
On Tue, 20 Sep 2022 11:00:13 +0200 andreas.fournier@runbox.com wrote:
On Tue, 2022-09-20 at 10:38 +0200, fedora wrote:
Don't you need to start pipewire as the normal user? i.e.
[host@non-root-user]$ systemctl restart pipewire-pulse.service --user
ah, right. When run as a normal user that command succeeds and in the log I can find
systemd[2290]: Stopping pipewire-pulse.service - PipeWire PulseAudio... systemd[2290]: Stopped pipewire-pulse.service - PipeWire PulseAudio. systemd[2290]: Started pipewire-pulse.service - PipeWire PulseAudio. rtkit-daemon[1231]: Successfully made thread 62005 of process 62005 (/usr/bin/pipewire-pulse) owned by '1000' high priority at nice level - 11.rtkit-daemon[1231]: Successfully made thread 62014 of process 62005 (/usr/bin/pipewire-pulse) owned by '1000' RT at priority 20. juno pipewire-pulse[62013]: 536870912
But still no audio.
Also tried 'aplay -D plughw:2,0 <audio file>'. No audio was produced.
This should have worked, if you have a speaker connected to the out port on the on board sound device (the green one). Headphones will also work. To pursue this further, start pavucontrol-pulseaudio, go to the third tab, output devices, and run the above command again. Do you see sound being sent to the device? Do you hear it? If you do, your sound is working, but you have a configuration issue
If you don't, go to the last tab of pavucontrol-pulseaudio, and turn off the built in audio. Run the above command again. Is there sound? Yes? The problem is in pipewire. No, maybe the volume isn't high enough. Run alsamixer -c 2 and raise the volume on the first bars until they are just in the red. Then, run the above command again. Is there sound? Yes? Sound is working but somehow the volumes were too low. No? I'm out of ideas. Given the data you showed, the built in audio should be producing sound if everything is configured properly (as I've described).
You can set up and try a new user, but be sure that you have logged out your current user before you try with the new user. The first user to log in gains total control over pipewire / pulseaudio unless it is being run as a server, which is not the default.
On 9/22/22 12:35, stan via users wrote:
You can set up and try a new user, but be sure that you have logged out your current user before you try with the new user. The first user to log in gains total control over pipewire / pulseaudio unless it is being run as a server, which is not the default.
Actually, switching users also switches control of the audio output. I haven't tried leaving something playing in the first user to see what happens, but when switching to a second user with the first one still logged in, the second user has sound.
On Thu, 2022-09-22 at 12:35 -0700, stan via users wrote:
On Tue, 20 Sep 2022 11:00:13 +0200 andreas.fournier@runbox.com wrote:
On Tue, 2022-09-20 at 10:38 +0200, fedora wrote:
Don't you need to start pipewire as the normal user? i.e.
[host@non-root-user]$ systemctl restart pipewire-pulse.service --user
ah, right. When run as a normal user that command succeeds and in the log I can find
systemd[2290]: Stopping pipewire-pulse.service - PipeWire PulseAudio... systemd[2290]: Stopped pipewire-pulse.service - PipeWire PulseAudio. systemd[2290]: Started pipewire-pulse.service
PipeWire PulseAudio. rtkit-daemon[1231]: Successfully made thread 62005 of process 62005 (/usr/bin/pipewire-pulse) owned by '1000' high priority at nice level - 11.rtkit-daemon[1231]: Successfully made thread 62014 of process 62005 (/usr/bin/pipewire-pulse) owned by '1000' RT at priority 20. juno pipewire-pulse[62013]: 536870912
But still no audio.
Also tried 'aplay -D plughw:2,0 <audio file>'. No audio was produced.
This should have worked, if you have a speaker connected to the out port on the on board sound device (the green one).
The audio came back yesterday, but hard to tell what was the culprit. Anyway yesterday I updated every package to the latest from repo and tested different things. I stumbled upon a software called PulseAudio Volume Control and in its Output Devices tab I fiddled with its knobs and suddenly the audio was back.
One thing that might also play into this is that the OS shows two output devices, when in reality I only have one monitor with built-in speakers that I've been using since always. Settings -> Sound shows two output devices, both named HDMI/DisplayPort - Built-in Audio. PulseAudio Volume Control shows Built-in Audio Digital Stereo (HDMI) twice.
Thanks for all the help
On Thu, 22 Sep 2022 15:35:05 -0700 Samuel Sieb samuel@sieb.net wrote:
On 9/22/22 12:35, stan via users wrote:
You can set up and try a new user, but be sure that you have logged out your current user before you try with the new user. The first user to log in gains total control over pipewire / pulseaudio unless it is being run as a server, which is not the default.
Actually, switching users also switches control of the audio output. I haven't tried leaving something playing in the first user to see what happens, but when switching to a second user with the first one still logged in, the second user has sound.
Well, your direct experience trumps my doc reading. But, how does that work? Unless the device has parallel paths, how can two people use the same device at the same time? And what about the speakers? I remember that it was a security issue when it was first implemented, to ensure that sound was not shared. At the time, if a sound played, everyone heard it. Perhaps, pulesaudio / pipewire have become more sophisticated and now tag sound and segregate it by user. Or maybe sound cards can process interleaved streams if they are tagged properly. Or, could it be tied to the screen visibility? Not questioning your experience, but wondering how it is implemented.
On Fri, 23 Sep 2022 08:46:51 +0200 andreas.fournier@runbox.com wrote:
The audio came back yesterday, but hard to tell what was the culprit. Anyway yesterday I updated every package to the latest from repo and tested different things. I stumbled upon a software called PulseAudio Volume Control and in its Output Devices tab I fiddled with its knobs and suddenly the audio was back.
Good news!
One thing that might also play into this is that the OS shows two output devices, when in reality I only have one monitor with built-in speakers that I've been using since always. Settings -> Sound shows two output devices, both named HDMI/DisplayPort - Built-in Audio. PulseAudio Volume Control shows Built-in Audio Digital Stereo (HDMI) twice.
Unless alsa has gone squirrely, the below is not your monitor. This is a sound device built into your MB, and should have ports on the case. The audio devices in monitors never have analog output, or at least I've never seen that. The ALC892 is a realtek chip installed on MBs to provide sound support. I guess it depends on what MB you are running, but I don't think any x86_64 MBs come without built in sound support. Maybe it is disabled / turned off?
card 2: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PCH [HDA Intel PCH], device 3: ALC892 Digital [ALC892 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0
On 9/23/22 08:17, stan via users wrote:
On Thu, 22 Sep 2022 15:35:05 -0700 Samuel Sieb samuel@sieb.net wrote:
On 9/22/22 12:35, stan via users wrote:
You can set up and try a new user, but be sure that you have logged out your current user before you try with the new user. The first user to log in gains total control over pipewire / pulseaudio unless it is being run as a server, which is not the default.
Actually, switching users also switches control of the audio output. I haven't tried leaving something playing in the first user to see what happens, but when switching to a second user with the first one still logged in, the second user has sound.
Well, your direct experience trumps my doc reading. But, how does that work? Unless the device has parallel paths, how can two people use the same device at the same time? And what about the speakers? I remember that it was a security issue when it was first implemented, to ensure that sound was not shared. At the time, if a sound played, everyone heard it. Perhaps, pulesaudio / pipewire have become more sophisticated and now tag sound and segregate it by user. Or maybe sound cards can process interleaved streams if they are tagged properly. Or, could it be tied to the screen visibility? Not questioning your experience, but wondering how it is implemented.
I believe it's something with the systemd session management. The display control gets transferred (no root permissions any more), so I don't think audio would be any harder.
On Fri, 23 Sep 2022 15:24:03 -0700 Samuel Sieb samuel@sieb.net wrote:
I believe it's something with the systemd session management. The display control gets transferred (no root permissions any more), so I don't think audio would be any harder.
That makes sense, a reasonable compromise. Because they have no way of controlling which audio output devices belong to which user, they have the audio switch with the visual, and let the user worry about who can hear their audio output.
-
andreas.fournier＠runbox.com -
fedora -
ja -
Samuel Sieb -
stan -
Ted Roche -
Thomas Cameron