Bug 480518

Summary:	Audio does not resume after screenlock or suspend/resume
Product:	[Applications] kasts	Reporter:	Chad Dougherty <dougherty477>
Component:	general	Assignee:	bart
Status:	RESOLVED DUPLICATE
Severity:	normal	Keywords:	qt6
Priority:	NOR
Version First Reported In:	24.01.90
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Selected audio backend in settings

Description Chad Dougherty 2024-01-30 03:06:36 UTC

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.

Comment 1 bart 2024-01-30 09:23:20 UTC

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.

Comment 2 Chad Dougherty 2024-01-30 13:03:22 UTC

(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.

Comment 3 Chad Dougherty 2024-01-30 13:04:06 UTC

Created attachment 165353 [details]
Selected audio backend in settings

Comment 4 bart 2024-01-30 13:24:11 UTC

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 ***