SUMMARY After recent switch to Fedora 34 Beta which introduced two changes at the same time: New Plasma 5.21.3 and pipewire, I'm not sure what is causing the behavior, so I've created a BZ for pipewire in Fedora and this one for plasma. There is a change in behavior for audio devices. Previously when new device is picked in Audio Applet, all audio immediately switched to a new device and from this moment all new audio is played through selected device. Now when new device is selected only audio that is played from this moment will be played from selected device, while existing audio stream continues to play through the old device. There is a new option to "Play all audio via this device" which is switching existing streams to play through the specified device, but all new streams still plays through the old device as this option does not change the device. Basically right now there is no way to achieve the old one-click effect without extra steps. I'm not sure what's the rational here, but I'd like to have some way of getting an old behavior in same amount of steps. If the intention was to provide some flexibility between existing and new streams, I'd suggest that "Play all audio via this device" also change the active device for the new streams as well. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 34 KDE beta (available in About System) KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80 Qt Version: 5.15.2 ADDITIONAL INFORMATION
Okay, funny enough after posting this BZ, I've got update for the pipewire and it fixed the problem, so please close it.
This is because PipeWire doesn't use the same code that PulseAudio does to cause active screams to switch automatically. So when you use the setting for "Automatically switch all running streams when a new output becomes available", nothing happens, because this setting only affects PulseAudio.
Active STREAMS! I meant active STREAMS!
But I guess if they fixed this in PipeWire's PulseAudio compatibility layer, that's good too.
(In reply to Nate Graham from comment #4) > But I guess if they fixed this in PipeWire's PulseAudio compatibility layer, > that's good too. It still happens right now, but generally it works with recent update. Cannot catch specific case when it's still happening
In that case I would definitely file a bug on pipewire or pulseaudio... not sure where anymore given the complexity of the audio stack nowadays. :(