Created attachment 175998 [details] Logs From Opening OBS Studio Using Pipewire and "Pro Audio" Audio Device Mode SUMMARY When opening some applications that use audio in some way (eg. OBS Studio or most games), using Pipewire, and using any audio device mode other than "Analog Stereo Duplex"; a popup showing the current volume of the device is shown having switched it to the "Analog Stereo Duplex" mode temporarily. A short moment later it will automatically switch it to whatever mode was originally selected. No audio can be heard in between the app starting and seeing the first popup indicating the audio device's mode switched to "Analog Stereo Duplex". STEPS TO REPRODUCE 1. Use Pipewire. 2. Switch the audio device to a mode other than "Analog Stereo Duplex". In my case the onboard audio of my motherboard, switching it to either "Pro Audio" or "Analog Stereo Output". 3. Open an affected application. OBSERVED RESULT Audio device momentarily switches to the "Analog Stereo Duplex" mode, then back to the originally selected mode. If audio is playing at the time this happens, playback is interrupted until the first popup shows the audio device switched to "Analog Stereo Duplex" mode. EXPECTED RESULT Audio device doesn't reset / close and audio playback is not interrupted while opening applications. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux - Kernel 6.11.8-arch1-2 KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION I attached a log I retrieved from journalctl from me launching OBS Studio. There is a lot of output in that log, but please take note of the lines mentioning "org.kde.pulseaudio". These lines are present in the log whenever I open any application that causes this bug to occur. Also this person on the KDE Discuss forums seems to have been experiencing this bug and found a workaround, but that workaround is switching to the "Analog Stereo Duplex" mode. https://discuss.kde.org/t/solved-audio-devices-resetting-when-joining-a-discord-call/25206
You'll want to file this against https://gitlab.freedesktop.org/pipewire/wireplumber and probably fetch a log with wireplumber debugging enabled with `wpctl set-log-level D` Our UI layer doesn't carry out device switches without user input AFAIK so this event chain must be coming from inside pipewire/wireplumber.
(In reply to Harald Sitter from comment #1) > You'll want to file this against > https://gitlab.freedesktop.org/pipewire/wireplumber and probably fetch a log > with wireplumber debugging enabled with `wpctl set-log-level D` > > Our UI layer doesn't carry out device switches without user input AFAIK so > this event chain must be coming from inside pipewire/wireplumber. Okay, thanks for tipping me off where to bring the bug to.
For anyone that finds this in the future, I reported this bug upstream here. https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/750