GNOME Bugzilla – Bug 651438
ogg/vorbis: sound hiccups occasionally in Banshee and Totem
Last modified: 2014-04-04 12:28:20 UTC
While listening to a sound file (the vast majority of my music is encoded with ogg), playback will hiccup occasionally, often getting slightly worse as the song progresses. I'm not sure where exactly the problem would be, since it occurs in Banshee and Totem, but not in VLC (which I don't think uses gstreamer), Audacious, or Rhythmbox; so I know it's not the sound files themselves.
Did this start happening recently? If yes, can you guess an approximate version when it did work and/or describe the circumstances? Could you attach a file in which this occurs?
Here is an example file: http://dl.dropbox.com/u/5330556/07%20-%20Come%20Out%20And%20Play.ogg On this file, a slight hiccup occurs regularly at the 17-second mark in both Banshee and Totem, but not in Rhythmbox or Audacious. I don't remember this always being a problem, so it definitely started recently. The version of gstreamer I'm using is from the Packman repository, and is slightly newer than what came with the standard openSUSE 11.4 install.
I can confirm this, happens with gstreamer but not with mplayer for example.
good theme =)
Created attachment 189284 [details] packages This problem also happened to me
Found some more information that may help narrow this down. The hiccup doesn't occur in Rhythmbox only as long as crossfading is enabled; if you disable crossfading in the preferences and restart the program, then Rhythmbox has the same problem that Banshee and Totem do. It occurs when testing the file with gst-launch (tested with 0.10.32) too. As far as I understand it, crossfading should only really affect the output when transitioning between sources, but in this case having it enabled is required in order for one sound file to play smoothly.
That file seems to have incorrect granulepos. vorbisdec forwards timings from the demuxer, and the base audio sink tries to correlate this with the number of samples, and inserts a discontinuity when the difference becomes too large.
While this does not fix the issue, this sample file exhibited a particularity of Vorbis - samples being discarded at start - which was not handled correctly. Fixed in https://bugzilla.gnome.org/show_bug.cgi?id=656412.
This file shows granpos mostly following decoded samples, but has a gap from time to time that stays constant over a short time before syncing again. The first gap is about 31 ms, appears at around 7.8 seconds, and disappears at around 8.2 seconds. This is not enough to trigger the discontinuity in the base audio sink code, but it you listen carefully you can hear the music get out of step. The second gap is about 51 ms, appears at around 17.5 seconds, and disappears at around 18 seconds. This is the one you mentioned, and it triggers the discontinuity, giving an audible pop. There are various others along the file, with increasing magnitude, reaching 103ms near the end of the file. As an experiment, I changed the timing of the buffers from the timestamps given by the container to an artificial one calculated from the number of decoded samples (aka a perfect timestamp) and playback does not suffer from the pops. I think this file was muxed by a buggy muxer. It should be possible to rewrite it with saner granpos losslessly though, as only the granpos seems to suffer from an intermittent offset.
I don't get the pops at the beginning with the current pre-releases (and GstAudioDecoder-based vorbisdec rewrite), but hear gaps at 1:52 and 2:04 after seeking. So close as WONTFIX because of broken file? Or is there something sensible we can do?
We could ignore timestamps from the granpos after the first timestamp is known. This may interact weirdly with seeking and position reporting. Also probably break A/V sync where there's a video as well. Remuxing via vorbisparse may well fix this file since the audio inside seems right, something like: gst-launch filesrc location=in.ogg ! oggdemux ! vorbisparse ! ooggmux ! filesink location=out.ogg I'd close it as NOTABUG.
i have the same problem with gstreamer 0.10.36 totem and rhythmbox in ubuntu 12.04 . but my problem is a sound pop in the beginning and when restart the music the song start in the second 1 not in the time 0 in others no gstreamer players player no have the problem . http://www.vorbis.com/music/ how to upgrade gstreamer ???
Closing since it's due to a bad input file. GIGO. If you know what muxer produced this file, it may be worth opening a bug on their tracker. rejuasjuas@hotmail.com, your second paragraph seems to be a different bug, though your first paragraph says it's the same. If it's a different bug, and if it still happens, then please open a new bug for it. To upgrade gstreamer, either use your distro's package management tools (eg, yum, apt-get, whatever else), or build it yourself (only if you know what you're doing).