Bugzilla – Bug 1221644
pipewire-pulse stops working when monitor powers off/on again
Last modified: 2024-05-22 19:54:07 UTC
I've observed this for some time. I have a triple monitor setup, and two of the three monitors have multiple devices plugged into them. When I lock my screen, one of the monitors switches to the Chromecast input automatically once DPMS kicks off the monitor, and when I switch it back on, pipewire-pulse refuses to play sound until I kill it *and* restart the application that was trying to play sound. This affects both sound input and output - I had a situation earlier today where the monitor was tuned back on (to keep the Chromecast from keeping the screen on all night, I turn it off using ddcutil to turn it off), and after killing pipewire-pulse, I was able to hear a web-based video call, but I could not be heard until I restarted Chrome (ie, my voice input - I tried both a bluetooth headset and a USB headset - would let me hear the other person on the meeting but they could not hear me and I could not control my microphone at all). It seems that a change in audio device availability - even a device that's not in use at he time (I rarely use the speaker on the monitor in question) causes pipewire-pulse to freak out and stop working properly until it is killed and restarts. Not sure what information would be useful from logs - let me know, and I'll see what I can grab.
I understand that your default audio device is an internal speaker in one of your monitors, right? First of all, can you send us the output of running the following command to see the versions of the relevant packages in your system? rpm -qa | grep -e pipewire -e wireplumber -e pulseaudio | sort Also, let's try to reduce the things happening. If you don't have a long audio file (something that lasts at least one minute), you can create one by running: ffmpeg -stream_loop 10 -i /usr/share/sounds/alsa/test.wav /tmp/long-test.wav And then, please test playing it with pw-play: pw-play /tmp/long-test.wav BTW, if you have some file around, I'd better use it, since that one can be a bit annoying when listening to it repeated over and over again. While the song is playing, try to turn off your monitor (not using dpms, but really off), wait 10 seconds and then turn it on again. The audio should still be playing after the monitor is turned on. Is it? As for logs that can provide some insight, it would be nice if you could send us the output of running `pw-dump` while audio is playing correctly, then the output of the command after turning the monitor off and once more after turning the monitor on again when audio doesn't work.
Thanks for the clarifying questions here. My default audio device is an Astro A40 Mixamp, with a USB microphone and an optical audio out. The HDMI monitors (I have two with audio capabilities) are not generally used for audio output. Here's the output of the 'rpm' command: ``` [jhenderson@TheEarth ~]$ rpm -qa | grep -e pipewire -e wireplumber -e pulseuadio | sort gstreamer-plugin-pipewire-1.0.4-1.1.x86_64 libpipewire-0_3-0-1.0.4-1.1.x86_64 libpipewire-0_3-0-32bit-1.0.4-1.1.x86_64 libwireplumber-0_5-0-0.4.90+git25.95cfa9e-1.1.x86_64 pipewire-1.0.4-1.1.x86_64 pipewire-alsa-1.0.4-1.1.x86_64 pipewire-aptx-1.0.1-1699.1.pm.1.x86_64 pipewire-devel-1.0.4-1.1.x86_64 pipewire-modules-0_3-1.0.4-1.1.x86_64 pipewire-modules-0_3-32bit-1.0.4-1.1.x86_64 pipewire-pulseaudio-1.0.4-1.1.x86_64 pipewire-spa-plugins-0_2-1.0.4-1.1.x86_64 pipewire-spa-plugins-0_2-32bit-1.0.4-1.1.x86_64 pipewire-spa-tools-1.0.4-1.1.x86_64 pipewire-tools-1.0.4-1.1.x86_64 wireplumber-0.4.90+git25.95cfa9e-1.1.x86_64 wireplumber-audio-0.4.90+git25.95cfa9e-1.1.noarch [jhenderson@TheEarth ~]$ ``` The test of the long audio file with the monitor powered off and back on again (using the power button on the monitor) did not cause the playback to fail, making me wonder if some other trigger is causing the issue. Indeed, this morning the audio seemed fine after having the monitor off all night. I also tried it with the monitor in question being the default output, and that also didn't cause it to stop playing. Attaching the working output of pw-dump. I'll grab one of it not working the next time I see it not working.
Created attachment 873668 [details] Output from pw-dump while audio playback is working
(In reply to Jim Henderson from comment #2) > Thanks for the clarifying questions here. My default audio device is an > Astro A40 Mixamp, with a USB microphone and an optical audio out. The HDMI > monitors (I have two with audio capabilities) are not generally used for > audio output. > Thanks for that information. The Mixamp is connected to an usb port in your computer and then connected to the headphone/speakers, is that right? Or is it connected to an usb port in a monitor? (I doubt because you mentioned in the description of the bug that your monitors "have multiple devices plugged into them"). > Here's the output of the 'rpm' command: That's perfect, those versions should be as good as the latest. > The test of the long audio file with the monitor powered off and back on > again (using the power button on the monitor) did not cause the playback to > fail, making me wonder if some other trigger is causing the issue. Interesting. Can you repeat the test but using paplay to play the audio file instead of pw-play? If paplay keeps playing audio too after turning off and on your monitor, then I'd try changing the experiment back to use dpms instead of turning off and on your monitor. While audio is playing (please test both pw-play and paplay) you can run something like the following to force the monitor to sleep for 10 seconds on X11: xset dpms force off ; sleep 10 ; xset dpms force on or if you're using kde on wayland: kscreen-doctor --dpms off ; sleep 10 ; kscreen-doctor --dpms on If you're using gnome (or some other desktop) on wayland, you'll have to trigger the screensaver to make dpms turn your monitor off.
Created attachment 873702 [details] Output from pw-dump when audio renderer is broken Checked this morning after having the system in its usual 'overnight' state, and the renderer wasn't functioning (Youtube reported an "audio renderer error" and asked that I restart my system. That's the symptom that I see typically when the issue pops up). Hopefully this will help narrow it down. The monitor in question was in a powered off state, and the other two were in DPMS sleep. I have a meeting coming up that I need to have audio for, so I have to restart pipewire-pulse to get ready for it. I saw there were some additional questions to answer, and I'll do that once the meeting's done.
(In reply to Antonio Larrosa from comment #4) > (In reply to Jim Henderson from comment #2) > > Thanks for the clarifying questions here. My default audio device is an > > Astro A40 Mixamp, with a USB microphone and an optical audio out. The HDMI > > monitors (I have two with audio capabilities) are not generally used for > > audio output. > > > > Thanks for that information. The Mixamp is connected to an usb port in your > computer and then connected to the headphone/speakers, is that right? Or is > it connected to an usb port in a monitor? (I doubt because you mentioned in > the description of the bug that your monitors "have multiple devices plugged > into them"). The Mixamp is an external device that takes the optical audio out from my PC and a USB connection for the mic, and feeds it to a mixer/amplifier for a headset with its own mic. The USB connection is plugged into the PC, not the monitor. > > The test of the long audio file with the monitor powered off and back on > > again (using the power button on the monitor) did not cause the playback to > > fail, making me wonder if some other trigger is causing the issue. > > Interesting. Can you repeat the test but using paplay to play the audio file > instead of pw-play? > > If paplay keeps playing audio too after turning off and on your monitor, > then I'd try changing the experiment back to use dpms instead of turning off > and on your monitor. While audio is playing (please test both pw-play and > paplay) you can run something like the following to force the monitor to > sleep for 10 seconds on X11: > > xset dpms force off ; sleep 10 ; xset dpms force on > > or if you're using kde on wayland: > > kscreen-doctor --dpms off ; sleep 10 ; kscreen-doctor --dpms on > > If you're using gnome (or some other desktop) on wayland, you'll have to > trigger the screensaver to make dpms turn your monitor off. I'm using X11 (just for future reference :) ). I should note that this "disconnect" happens even when the monitor isn't selected as the output device. I'm wondering if maybe the monitor being off is a red herring....It may be a case of correlation rather than causation. Turning the monitor off and on while playing during paplay didn't result in it disconnecting. Same with pw-play, and when forcing it off using DPMS. I also tried using my script that I use to turn it off (and the script to turn it on again) when I wrap up for the day. Here's what's in those scripts: --- delloff.sh --- #!/bin/bash ddcutil setvcp -n 8YTRWP2 d6 0x05 dbus-send --type=method_call --dest=org.gnome.ScreenSaver \ /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock ---end--- --- dellon.sh --- #!/bin/bash ddcutil setvcp -n 8YTRWP2 d6 0x01 ddcutil setvcp -n 8YTRWP2 60 0x11 ---end--- Capability d6 is used to set the power mode. 0x01 is "DPM on, DPMS Off". 0x05 is defined as "Write ony value to turn off display". Capability 60 is to set the input source; value 0x11 sets the input to HDMI-1 (which is one of my video card's HDMI connections). The video card, BTW, is an nVidia 3090ti, using the proprietary G06-550.54.14-20.1 driver. It's strange that I can't seem to reproduce it at will.
Just an update - went a couple of days without it happening, and then this morning it happened again, post-update to GNOME 46. Updated RPM list output: gstreamer-plugin-pipewire-1.0.4-1.1.x86_64 libpipewire-0_3-0-1.0.4-1.1.x86_64 libpipewire-0_3-0-32bit-1.0.4-1.1.x86_64 libwireplumber-0_5-0-0.5.0-1.1.x86_64 pipewire-1.0.4-1.1.x86_64 pipewire-alsa-1.0.4-1.1.x86_64 pipewire-aptx-1.0.1-1699.1.pm.1.x86_64 pipewire-devel-1.0.4-1.1.x86_64 pipewire-modules-0_3-1.0.4-1.1.x86_64 pipewire-modules-0_3-32bit-1.0.4-1.1.x86_64 pipewire-pulseaudio-1.0.4-1.1.x86_64 pipewire-spa-plugins-0_2-1.0.4-1.1.x86_64 pipewire-spa-plugins-0_2-32bit-1.0.4-1.1.x86_64 pipewire-spa-tools-1.0.4-1.1.x86_64 pipewire-tools-1.0.4-1.1.x86_64 pulseaudio-setup-17.0-4.1.x86_64 pulseaudio-utils-17.0-4.1.x86_64 pulseaudio-utils-32bit-17.0-4.1.x86_64 wireplumber-0.5.0-1.1.x86_64 wireplumber-audio-0.5.0-1.1.noarch I thought I'd try also looking at what pavucontrol showed as well, and it just says "Establishing connection to PulseAudio. Please wait..." dmesg shows nothing related to audio devices or issues. Attempting to use 'amixer -D pulse' returns: $ amixer -D pulse sset Master toggle ALSA lib control.c:1570:(snd_ctl_open_noupdate) Invalid CTL pulse amixer: Mixer attach pulse error: No such file or directory Wasn't able to find anything else - killing pipewire-pulse restarted it as before. Hopefully there's some additional info here that helps.
Does the problem persist with the latest updates? There is a known issue of wireplumber about the HDMI monitor changes (e.g. bsc#1222651), and you might be hitting it. The upstream tracker shows: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/613
I still see it intermittently, but haven't updated since 20240505 came out (I thought I had updated since then, but it seems I haven't). In my instance, I'm not switching between inputs, nor is the HDMI output active often. That said, I'll update today and keep an eye out for the next time it happens, and when it does, I'll look in the GNOME sound settings and see what it shows for devices and their status.
I've just had it happen again, currently on 20240517. pavucontrol just spins when I try to bring it up. When I look in the gnome sound settings, it just says "no output devices" and "no input devices". The pre-existing list does show in the gnome menu (ie, clicking the upper-right part of the toolbar to get the volume controls).
Something that maybe is useful - I noticed that the wireplumber user service unit shows the following today: --- May 22 11:30:56 TheEarth wireplumber[3647]: [string "alsa.lua"]:178: table index is nil stack traceback: [string "alsa.lua"]:178: in function <[string "alsa.lua"]:172> ---