SUMMARY When resuming playback of a podcast after either suspend/resume or unlocking a locked session, the audio does not resume immediately. The counter advances as though play is resumed, but audio is not produced for a random amount of time, anywhere between seconds or minutes. STEPS TO REPRODUCE 1. Start the playback of a podcast episode (I only tested via already-downloaded items), then pause the playback 2. Lock the session with Windows-L or other method 3. Unlock the session, and hit play in the Kasts window. Observe that the time counter is advancing yet no audio is produced. OBSERVED RESULT No audio plays even though the time counter is advancing. EXPECTED RESULT I'd expect the audio to start again almost immediately. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora Rawhide/6.0 RC1 (available in About System) KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION This could be a deeper problem with the audio system, as I also notice a slight audio delay with Elisa and a local music file as well.
I'm pretty sure this is a duplicate of 473648 (https://bugs.kde.org/show_bug.cgi?id=473648). I checked the fedora package dependency list, and it seems that Kasts is compiled with only the qt-multimedia-gstreamer backend. This is extremely buggy. The symptoms that you are describing exactly match my experiences. Before I flag this as a duplicate, can you check in the general settings of Kasts which backend is selected to confirm that this is the likely cause? NB: I'm currently working on a solution that hopefully solves all the backend related bugginess and platform weirdness.
(In reply to bart from comment #1) > Before I flag this as a duplicate, can you check in the general settings of > Kasts which backend is selected to confirm that this is the likely cause? > It says Qt Multimedia, and that it is the only option. See attachment.
Created attachment 165353 [details] Selected audio backend in settings
Ok, thanks for confirming. Then I'm afraid that it's actually the gstreamer bug. This may explain the same thing happening in elisa, because that's also compiled with the same qt-multimedia/gstreamer backend on fedora... There's currently nothing I can do to solve this, other than work harder on the backend replacement. :-) In the meantime, you could try and convince fedora to compile Kasts with the vlc backend. But I'm not sure if they're going to be willing to do that. *** This bug has been marked as a duplicate of bug 473648 ***