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