SUMMARY When an application is recording sound, when selecting the application tab Plasma starts thinking all the audio was disconnected and connected in a loop. When I switch back to the Devices tab everything is back to normal. See this, quite poor, video to better understand what is going on: https://gfycat.com/accurateimprobabledutchshepherddog STEPS TO REPRODUCE 1. Start an application that records audio 2. Open the Sound panel and switch to the Applications Tab OBSERVED RESULT Plasma is showing as if all the audio devices have disconnected and then after a few seconds connected back up again. This happens in a loop until you switch back to the Devices tab or close the applet. Then everything is back to normal. EXPECTED RESULT Just be able to see the list of applications that are playing and recording sound. This started happening around plasma 5.23~5.24 I think, I haven't seen this behavior before. For completeness I'm using pipewire and Wayland. There is no problem with the sound while this is happening, it just looks like a display issue.
I am suffering this bug for a while, if I recall correctly even before Plasma 5.25. For me, when I open the devices tab, if I am using the microphone, I see the panel flicker between and empty device with the "There are not apps playing or recording sound" message, and the current apps doing it. The loop is so fast than I can hardly see the apps for tenths of a second. I am using the X11 session in my main computer but I think that this happens also in the wayland session in my work laptop
I could not reproduce it with Audacity 3.1.3-beta-20220626 on openSUSE TW using Plasma 5.25.3 Wayland.
(In reply to postix from comment #2) > I could not reproduce it with Audacity 3.1.3-beta-20220626 on openSUSE TW > using Plasma 5.25.3 Wayland. I think this was a issue in pipewire, I have upgraded to a newer version from the PPA and it went away. In any case didn't seem related to KDE. So as far as I'm concerned we can close this.
Indeed update to latest version of pipewire from PPA solved the issue. Thanks for the info!
Seems like this was (unsurprisingly) caused by a bug deeper in the audio stack.