GNOME Bugzilla – Bug 757225
Freezing with crossfade backend
Last modified: 2018-05-24 18:35:24 UTC
Steps to reproduce 1: Play a song 2: Pause it 3: Resume 4: Forward to next track happens on latest git as of this report. On Arch. The interesting part is that the freeze seems to last the duration of the pause.
I am also affected by this bug on Ubuntu 15.10. It happens on all Rhythmbox versions (even ones that worked before), after the upgrade from 15.04. I also noticed that the duration counter seems to get "confused". ( https://vps.tasossah.com/bugs/rhythmbox_xfade.jpg ) The bug can easily be reproduced with the steps mentioned by the bug reporter on a Ubuntu 15.10 Live CD/ISO inside a Virtual Machine.
Created attachment 314587 [details] debug info when the issue occurs.
I am unable to reproduce this. What versions of GStreamer and its plugin packages do you have installed? Does this happen for all file types, or just mp3? What mp3 decoder plugin(s) do you have installed?
I just realised that the bug reporter probably meant that the UI freezes. In my case the UI is still responsive, but the application has no control over the track that is currently playing, and then the music stops after some time (depending on the pause duration). I think they are both caused by the same issue, however apologies if the bug is not the same. From what I have seen the issue is format-independentas I have encountered it while playing flac, mp3 and opus music files. The version of gstreamer installed in my system is the one that comes with Ubuntu, which is 1.6.0. Here is a list the gstreamer1-related packages in my installation: https://vps.tasossah.com/bugs/gstreamer.txt As I mentioned earlier, this can be reproduced with a couple of flac files on a stock Ubuntu 15.10 ISO in a VM, without even needing to install it. This leads me to believe that it is not a change specific to my system, but possibly a change in gstreamer or another library.
I'm on arch with latest gstreamer(well, everything i guess). All gstreamer plugins are installed. Happens to me with all types.
(In reply to rosenp from comment #5) > I'm on arch with latest gstreamer(well, everything i guess). All gstreamer > plugins are installed. Happens to me with all types. This isn't very helpful. Please give actual version numbers. It appears that this only happens with the pulsesink in gst-plugins-good 1.6.x as I've tried alsasink and sndiosink on machines with gstreamer 1.6.x without seeing it, while I do see it with pulsesink on one of those machines.
from pacman -Q: gst-libav 1.6.1-1 gst-plugins-bad 1.6.1-1 gst-plugins-base 1.6.1-1 gst-plugins-base-libs 1.6.1-1 gst-plugins-good 1.6.1-1 gst-plugins-ugly 1.6.1-1 Can't say i have any idea how to switch to alsasink or sndiosink. Pulseaudio is at version 7.1 on this machine. I use it since gnome requires it.
I haven't had any time to look at this until today, but I think I've figured it out now. When all streams are paused, rhythmbox is still playing a silent stream (ideally it would pause the sink completely, but this doesn't work for various other reasons). The buffers that make up this stream have the 'gap' flag set on them which allows downstream elements to skip processing them. As part of fixing bug 735666, the audio sink base class started dropping gap buffers rather than rendering them. Most audio sinks seem to insert silence by themselves to fill in gaps between buffers rendered to them, but pulsesink doesn't. The pulseaudio server then sees a gap in the stream it gets from rhythmbox, resulting in silence, and I'm guessing it also messes up gstreamer's idea of the stream timestamp too. We can work around this by playing extremely quiet noise instead of silence, but this is a pretty horrible thing to have to do.
commit 039da36 works around this by using appsrc to produce silence rather than audiotestsrc. the buffers appsrc produces don't have the GAP flag set, so they don't cause pulsesink to do bad things.
*** Bug 761289 has been marked as a duplicate of this bug. ***
After much testing and waiting for some other bugs to get fixed, as well as upgrading Pulseaudio to version 7, the issue seems to be completely resolved. Thank you!
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/1424.