Bug 307530 - abouttofinish locking continues to break games
Summary: abouttofinish locking continues to break games
Status: RESOLVED FIXED
Alias: None
Product: phonon-backend-gstreamer
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.6-git
Platform: unspecified Linux
: NOR normal
Target Milestone: 4.7
Assignee: Harald Sitter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-28 13:46 UTC by Harald Sitter
Modified: 2012-12-04 09:25 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.6.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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