Bug 307530

Summary: abouttofinish locking continues to break games
Product: [Frameworks and Libraries] phonon-backend-gstreamer Reporter: Harald Sitter <sitter>
Component: generalAssignee: Harald Sitter <sitter>
Status: RESOLVED FIXED    
Severity: normal CC: myriam, romain.perier, tdfischer
Priority: NOR    
Version: 4.6-git   
Target Milestone: 4.7   
Platform: unspecified   
OS: Linux   
Latest Commit: http://commits.kde.org/phonon-gstreamer/431ab9bf3072a96ae039d586195598e62800b6b9 Version Fixed In: 4.6.3

Description Harald Sitter 2012-09-28 13:46:33 UTC 
The kde game pairs exposes a new problem with timed waiting in the abouttofinish cb...

pairs uses *one* MO to play multiple sounds from a qbuffer. To achieve sane results it only calls setCurrentSource iff the MO is not in playing state. Iff it is in playing state a one-source-queue is maintained, so that only the most recent sound would be played after the present one. Therein lies the problem.

Assuming on second length of the sound what happens is that phonon starts playing, then immediately gets the callback to queue a new track. It emits the queued signal and locks for 3 seconds. So, for a period of <=4 && >=3 seconds the MO is in playing state but not actually playing anything.
During this period pairs will enqueue tracks but they will not be played.


Reproducible: Always
Comment 1 Harald Sitter 2012-12-04 09:25:37 UTC 
Git commit 307f10460ae1786d4167520d495984f2eb24f9a8 by Harald Sitter.
Committed on 04/12/2012 at 10:25.
Pushed by sitter into branch '4.6'.

Dynamic lock timeout is our friend.
Instead of simply waiting for a fixed amount of ms for the next source,
we wait for the most sensible amount of time. This is whatever amount
of time is remaining to play minus a 0.5 seconds safety delta (time
values not precise etc.).
A source for which we have no time or for which the remaining time is
< 0.5 seconds is immediately unlocked again. Otherwise the consumer has
as much time as gst gave us to set a new source.
This in particular prevents pointless excessive locking on sources which
have a totalTime < whatever fixed lock value we have (so that we'd lock
longer than what we are playing). An issue apparent with notification-like
sounds, that are rather short and do not need gapless transitioning.
FIXED-IN: 4.6.3

Conflicts:
	gstreamer/mediaobject.cpp

M  +34   -15   gstreamer/mediaobject.cpp

http://commits.kde.org/phonon-gstreamer/307f10460ae1786d4167520d495984f2eb24f9a8
Comment 2 Harald Sitter 2012-12-04 09:25:44 UTC 
Git commit 431ab9bf3072a96ae039d586195598e62800b6b9 by Harald Sitter.
Committed on 04/12/2012 at 10:24.
Pushed by sitter into branch 'master'.

Dynamic lock timeout is our friend.
Instead of simply waiting for a fixed amount of ms for the next source,
we wait for the most sensible amount of time. This is whatever amount
of time is remaining to play minus a 0.5 seconds safety delta (time
values not precise etc.).
A source for which we have no time or for which the remaining time is
< 0.5 seconds is immediately unlocked again. Otherwise the consumer has
as much time as gst gave us to set a new source.
This in particular prevents pointless excessive locking on sources which
have a totalTime < whatever fixed lock value we have (so that we'd lock
longer than what we are playing). An issue apparent with notification-like
sounds, that are rather short and do not need gapless transitioning.
FIXED-IN: 4.6.3

M  +34   -15   gstreamer/mediaobject.cpp

http://commits.kde.org/phonon-gstreamer/431ab9bf3072a96ae039d586195598e62800b6b9