Bug 299293 - ktuberling gets stuck when clicking on two items quickly and having sounds activated
Summary: ktuberling gets stuck when clicking on two items quickly and having sounds ac...
Status: RESOLVED FIXED
Alias: None
Product: phonon-backend-gstreamer
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.6
Platform: unspecified All
: HI major
Target Milestone: 4.6.1
Assignee: Torrie Fischer
URL:
Keywords: regression, release_blocker
Depends on:
Blocks: 301346
  Show dependency treegraph
 
Reported: 2012-05-03 11:55 UTC by Allan K
Modified: 2012-08-02 12:10 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.6.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan K 2012-05-03 11:55:13 UTC
Trying potato guy on a new install of Ubuntu 12.04, ktuberling response is too erratic to be playable.
clicking on items to drag there is an erratic delay often a second or more before the word is sounded and item can be dragged

Reproducible: Always

Steps to Reproduce:
1.click, drag & drop items on to potato guy 
2.
3.
Actual Results:  
on clicking item there is a delay before the item name is sounded
the item may not be drag-able for a number of seconds.
delays are erratic

Expected Results:  
click on item the, the item name should sound as clicked and should be immediately drag-able onto potato guy.
Comment 1 Albert Astals Cid 2012-05-10 18:18:40 UTC
Works here, we have changed nothing in the code so I suspect it's something else changed in the Ubuntu infraestructure (like the graphics driver).

Are you using Unity, Unity2d, gnome shell, kde plasma shell, something else?

Does running 
ktuberling --graphicssystem raster
from a terminal help?
Comment 2 Allan K 2012-05-10 20:36:25 UTC
I am seeing the same behaviour using both Unity and Unity2D.
There is an outstanding issue with the nvidia proprietary graphics driver in 12.04 distribution so I am running with Ubuntu drivers (I think it maybe nouveau, do you know how I can check?).

I'm monitoring the nvidia bug
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982485 

I tried running the suggested command in terminal, behaviour is still the same, 
Is the output from the command any help?
Comment 3 Allan K 2012-05-10 21:01:17 UTC
Further attempts at the game seem to show that the problem lies in a delay is between clicking an item and the name being sounded. If I hold the click until the sound is played, then the item can be dragged and dropped ok. The delay between the click and the sound is erratic, occasionally near instantaneous but more often is a couple of seconds or more.
Comment 4 Albert Astals Cid 2012-05-10 21:16:31 UTC
Interesting.

Which phonon backend are you using?

dpkg -l | grep phonon
Comment 5 Allan K 2012-05-10 22:16:20 UTC
dpkg -l | grep phonon
ii  libphonon4                             4:4.7.0really4.6.0-0ubuntu1             multimedia framework from KDE - core library
ii  phonon                                 4:4.7.0really4.6.0-0ubuntu1             multimedia framework from KDE - metapackage
ii  phonon-backend-gstreamer               4:4.7.0really4.6.0-0ubuntu1             Phonon GStreamer 0.10.x backend
Comment 6 Albert Astals Cid 2012-05-24 18:24:31 UTC
So everything works fine if you disable sounds?
Comment 7 Allan K 2012-05-24 18:35:45 UTC
Haven't tried. How do I disable sounds?
Comment 8 Albert Astals Cid 2012-05-24 18:44:38 UTC
In the Speech menu.
Comment 9 Allan K 2012-05-24 19:29:24 UTC
Your hunch seems right, it appears to run fine with no sound option.
Are there known issues with the phonon backend ?
Comment 10 Albert Astals Cid 2012-05-28 20:02:24 UTC
Not really, i'm actually using Ubuntu 12.04 too and i have no issues with the phonon backend and actually looking at the code i don't see why waiting for the sound to finish or not should have any effect. I'm afraid without further information (which would basically be me having access to your computer or any other where the problem happens) it's kind of impossible to fix this issue.
Comment 11 Albert Astals Cid 2012-05-28 20:19:48 UTC
Actually i can reproduce it. It is a phonon regression.
Comment 12 Myriam Schweingruber 2012-05-30 13:26:08 UTC
Is this also reproducible with the phonon-backend-vlc?
Comment 13 Harald Sitter 2012-05-30 14:00:01 UTC
No it is not. Something is fishy with the pgst pipeline, which keeps it busy up until a couple of seconds after playback ended, if one sets a new track in that time frame it locks up the calling thread as the pipeline is still busy doing cleanup or something.
Comment 14 Albert Astals Cid 2012-05-30 14:20:13 UTC
this is random stuff because bugzilla doesn't let me change it back to new
Comment 15 Allan K 2012-05-30 14:47:28 UTC
I have installed phonon-backend-vlc package and set as preferred backend before GStreamer.
Potato Guy appears to be working fine with this backend.
Comment 16 Myriam Schweingruber 2012-05-30 15:36:47 UTC
Thank you all for the fast feedback. Reassigning to the gstreamer backend, then
Comment 17 Harald Sitter 2012-06-07 11:45:55 UTC
Turns out for gapless playback a mutex lock was introduced in the aboutToFinish emission to give the frontend time to feed a new track before the old one actually finishes. For short tracks that of course causes an intermediate deadlock (until the waitcondition times out) because the pipeline won't accept a new source while being locked waiting for a new track via setnextsource.

That of course is a behavior breakage and major annoyance as it makes simple use cases more complicated, hence for 4.6.1 we'll regress gapless in favor of restoring original behavior for short track playback by removing the mutex. That is of course unless a solution to address both is found in time.
Comment 18 Torrie Fischer 2012-06-13 14:04:16 UTC
Fixed in 620e8d39793fe4c32e1797f7c4957d04c51e8b23
Comment 19 Harald Sitter 2012-06-18 00:31:53 UTC
Verification failed. This only fixes the issue because it breaks the gaplessness entirely (namely skipGapless is always false, thus never actually locking).

For 4.6.1 the locking should be removed entirely to prevent corner case hickups, in master we should look into a solution that reintroduces gaplessness and allows lockfree usage.

In particular the problem is that a statechange must interrupt the aboutToFinish lock for gapless playback, which is trivial enough to implement. However gstreamer then for some odd reason triggers another callback (supposedly due to the statechange) which then needs to properly time out, those callbacks then apparently pile up and a) let sound get lost b) leave the MO in an undefined state as the function is not particularly reentrant.
In ktuberling specifically it calls setSource while we handle abouttofinish, which implicitly calls stop() (libphonon does that) which then triggers the statechange. However, it seems even if the statechange is removed it still at some point tends to pile up callbacks. Not quite sure why.

Anyhow, further analysis is needed here as is an immediate fix via 4.6.1.
Comment 20 Harald Sitter 2012-08-02 12:10:48 UTC
Should be fixed for 4.6.2 properly now.