Bug 99559 - Gap between songs with gstreamer and xine engines
Summary: Gap between songs with gstreamer and xine engines
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.2
Platform: Unlisted Binaries Linux
: NOR wishlist with 121 votes (vote)
Target Milestone: ---
Assignee: Amarok Developers
: 96689 106278 106353 109086 114377 (view as bug list)
Depends on:
Reported: 2005-02-16 22:13 UTC by Jeff Mitchell
Modified: 2006-07-12 03:32 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Mitchell 2005-02-16 22:13:56 UTC
Version:           1.2 (using KDE KDE 3.3.2)
Installed from:    Unspecified Linux


amaroK 1.2 makes everything else look like a toy media player.  I used to miss Winamp when I wasn't working in Windows.  Now I miss amaroK when I'm working in anything else.  It's just such a joy to use.

That having been said...

When playing songs back with the xine or gstreamer engines (I haven't tried aRTs as I have the aRTs system disabled generally) I experience a gap between songs.  I've tried turning off crossfading and setting the gap to 0ms (for both engines) and it doesn't work...with the xine engine I have maybe 100ms of gap, enough for a little gap to be noticeable, and with gstreamer I have a gap that can last nearly a second, which is really annoying, and surprising since it's supposed to be the best engine of the three.

My music collection consists of FLAC and MP3 files, and the same behavior occurs on each.  It might be my setup -- for various reasons I have my default ALSA device, which both engines use, set as a plug device instead of just linking to hw0:0, but even if that's the reason for the small gap with xine, it doesn't explain the huge gap with gstreamer.

Hope you guys can help.  I'm using KDE RPMs from the kde-redhat project on Fedora Core 3.

Comment 1 Iñaki Baz Castillo 2005-02-21 02:54:04 UTC
My system: AMD 2200 MHz - RAM 256 MB - Debian Sid
Amarok 1.2 from http://archive.kalyxo.org (for Debian)

In amaroK 1.2-beta4 arts worked really fine, fast and without gaps, not like in previous versions. But now, in amaroK 1.2 arts works wrong again, it "eats" the first 0,5 seconds playing a song.

GStreamer works really wrong in my system, long gaps and very slow starting and stopping the song. Doesn't play CDs and mpc files.

Xine is now the best engine in my system but it doesn't allow to play CDs or mpc files. And arts in amaroK 1.2-beta4 worked better (faster) than xine.

I have done a lot of tries with all the options (crossfading, etc).

Why GStreamer is said the best engine and runs so badly in my system?
I hope a definitive stable and powerful engine for amaroK.
Comment 2 Jeff Mitchell 2005-02-21 15:46:02 UTC
I guess I should mention that I also have the issue with it "eating" the first 0.1-0.5 seconds of a song when starting it.  If I am playing a song and double-click on another to start playing it, or if it switches over from one song to another (with the aforementioned gap) then I don't lose anything.

However, if I start playing a song from a stopped state, then first 0.1-0.5 seconds of the song are usually lost.

ibc, can you please confirm these bugs so that this will get looked at?
Comment 3 Iñaki Baz Castillo 2005-02-21 17:07:39 UTC
My system: AMD 2200 MHz - RAM 256 MB - Debian Sid 
Amarok 1.2 from http://archive.kalyxo.org (for Debian) 

-arts: the first 0.1-0.5 seconds of the songs are ALWAYS lost (doing double click in another song, playing from stop, switching the song, etc).

-xine: no gaps, it works well, but arts worked better in the previous version (amaroK 1.2-beta4).

-gstreamer: really bad, gaps a lot and very very slow starting or stopping a song.
Comment 4 Matiss Piesins 2005-03-10 16:14:05 UTC
To me it seems like the gstreamer is simply to "heavy" - when I have the crossfading on, it makes a quite annoying pause before the new fading-in song starts. This, happens with the processor running at 800 or 1600 MHz. When set manually to 2 GHz it usually doesn't make any gaps.

(it's an athlon64 3200+, which, even at 800 Mhz, is reasonably "powerful" to play a pair of mp3 simultanously)

xine was a nice engine without gaps when crossfading (with alsa dmix), but crossfading is now (since 1.2) disabled and the whole thing crashes when the last song ends  :(
this would not be anything terrible, if it did not take X down...
(I'll rebuild it with debug to find the problem, hopefully)
Comment 5 Mark Kretschmann 2005-03-10 16:50:33 UTC
On Thursday 10 March 2005 16:14, Matiss Piesins wrote:
> ------- Additional Comments From piesis navigator lv  2005-03-10 16:14
> ------- To me it seems like the gstreamer is simply to "heavy" - when I
> have the crossfading on, it makes a quite annoying pause before the new
> fading-in song starts. This, happens with the processor running at 800 or
> 1600 MHz. When set manually to 2 GHz it usually doesn't make any gaps.

amaroK 1.2.2 will contain a fix for this issue.
Comment 6 Jeff Mitchell 2005-03-10 16:56:02 UTC
I also get an annoying pause before the new fading-in song begins when using the Gstreamer engine.  When one song is about to end, there is a pause in the music for a moment, then the new song and the old one crossfade.

I've been doing some other tests and have found that the "eating" of the first part of a song does not occur with the Xine engine, only with Gstreamer.  What's more, it doesn't happen the very fist time a(ny) song is played.  So when I open amaroK using the Gstreamer engine, and start playing a song, the first part of it does not get cut off.  However, any other song that is played after that has the first parts eaten (I've turned off crossfading to check this).

If I'm having this problem with a file, then close amaroK and reopen it, the song then plays fine -- the first song, the first time, that is.

So maybe there's some Gstreamer buffering issues?  That would help explain both the song startup issues and the pausing before crossfading issues -- which could be one and the same since either way I'm getting silence before new songs start.
Comment 7 Jeff Mitchell 2005-03-10 16:56:50 UTC
...sorry, you submitted your reply while I was typing mine...so do you think that the problems I described above will also be fixed in amaroK 1.2.2?

Comment 8 Max Howell 2005-03-10 23:16:24 UTC
xine-engine crashes when the playlist ends? Nonsense. Playlist end is irrelevent to the engine. Is this reproducible? I doubt it.
Comment 9 Krzysztof Wozniak 2005-03-11 00:19:12 UTC
current amarok-CVS (20051003) has the gap problem with GStreamer engine ! 
with my investigation i found that:

Gap is longer and more annoying in each new gstreamer engine release.

Gap is strongly connected with gst_init function: it is called every time new song is played (new stream opened) and it is very resource hungry. In my case it "hangs" everything (gui, analyser, etc.) for about 0,2-0,5 sec. (I have P4 1,8ghz with plenty of RAM).
every time amarok call gst_init gstreamer engine loads registry.xml and plugins and it takes long and blocks playing of current song.

Xine works perfectly (but without crossfading it is useless)
aRts works perfectly (but without equaliser it is ... ;-)  )

I see following posible ways to address this problem:

1. Maybe it is possible to call gst_init only once in application ??

2. If not, maybe there could be solution with manipulating of thread priorities ! (you could give current playing song higher priority than starting next song thread)

3. Definitely restoring xine crossfading capability will solve all my current problems ;-) 

Comment 10 Iñaki Baz Castillo 2005-03-15 16:06:55 UTC
*** This bug has been confirmed by popular vote. ***
Comment 11 Max Howell 2005-03-15 22:41:12 UTC
For 1.3 I would like to experiment with preloading the next track a few seconds before change or crossfade. Hopefully this will solve this immediate issue. xine-crossfading will return when I can be bothered to write my own volume handling element.
Comment 12 Rodney Gordon II 2005-03-24 17:41:19 UTC
1.2.2 does not solve this problem, in fact, it may be worse. For starters, I am using gstreamer/alsasink w/ no crossfade, gap 0, fade in/out 0.

Instead of having a gap that doesn't really show visually with older releases, with gstreamer the next song will usually start with the time counter on 6 seconds, and then sit there silent for 6 seconds, and cuts off the song's 6 seconds before playing!

This is also worse if the system has any substantial load. It may help if I put amarok into SCHED_ISO (ck kernels) but, due to the large jump in load whenever gstreamer loads another song, in SCHED_ISO amarok will freeze my whole system for a few seconds :/

If it helps any, I only play FLAC (mostly), MP3 and OGG.
Comment 13 Matiss Piesins 2005-03-25 13:47:35 UTC
Those gstreamer skipping problems are gone (since CVS build from ~23 March)
I'm taking away my votes  :)

About that crashing after last song:
1) initially (version ~1.2.1) it was triggered by xine-engine, though not beeing directly its fault
2} with next version it did not crash totally, just flooded the console with some size related errors - so it is connected with OSD. It was so with all engines and disappeared with OSD swithed off
3) with a CVS build from ~16th March OSD worked fine when it had an album picture to show, otherwise or at the end of the playlist it showed a black, scrambled area at the top of the screen, where OSD should be, but in full width (I didn't mind that, given other amaroK's features ;)
4) with a CVS build from ~23 March, with OSD on it did not show anything at the end of the playlist, or when the album has no cover image ???

to conclude - things have changed so rapidly, that I dont even have any useful info to report (just some noise ;), but the good news are that, whatever the OSD problem was, it is now almost solved and the 1.2.3 version will be a very good one!

^^^ that was a bit off-topic, sorry.
Comment 14 Matiss Piesins 2005-05-05 01:20:19 UTC
:(   back are my votes...
it makes gaps again, my comment about this same bug: http://bugs.kde.org/show_bug.cgi?id=102708#c5
Comment 15 Alexandre Oliveira 2005-05-05 02:13:58 UTC
*** Bug 96689 has been marked as a duplicate of this bug. ***
Comment 16 Alexandre Oliveira 2005-05-25 17:05:18 UTC
*** Bug 106278 has been marked as a duplicate of this bug. ***
Comment 17 Alexandre Oliveira 2005-05-27 00:41:21 UTC
*** Bug 106353 has been marked as a duplicate of this bug. ***
Comment 18 Matiss Piesins 2005-06-03 16:43:29 UTC
to me, it looks more and more that this gap occures not because of the backend (gst or xine, though they could do better as well), but because of those many jobs amarokapp is doing at songchange, especially - rendering the new context page in khtml.

I have noticed occasional gaps in playback just because gecko or khtml are rendering some web page. My guesses are that the gap occures at the moment when the renderer is pushing the newly compiled page (a big vector graphics image) on screen.

One other possible gap source is CPU's frequency changing which, according to some rumors and kernels config texts, is technically quite a complex thing and introduces short offline states of CPU and FSB. That, in turn, may confuse kernel's scheduler and introduce some disorder with timeslices. (I'm not confident what I'm talking about, it's just intuition...)

Perhaps preloading of the next track together with delayed db lookups/context panel rendering could do the trick?
Comment 19 Jeff Mitchell 2005-06-03 18:37:15 UTC
That's an interesting theory. I can't test it at the moment -- it will be several weeks before I can, because I noticed these issues when loading songs from my mini-NAS, which is currently in a different city than me. However, when I was using the "ondemand" cpu frequency governor, I would experience some very annoying problems in X related to dropped interrupts when the frequency changed. So it's possible that it is causing some sort of problem.  When I get in the same state as my networked hard drive, I'll give this a go with the ondemand governor and see if that makes a difference.

I should mention that I haven't noticed this problem recently on my machine. It might have been fixed for me due to changes in recent versions of amaroK, or even because I no longer use the ondemand governor, but I've left the bug report alone because others have written with similar problems and I'm not sure how they've been getting along.  Once I get back with my music, if I don't have these issues anymore, I'll remark on it and close the report, unless someone else pipes up saying that they still have the problem.

Regardless of whether the problem is fixed or not, the khtml thing might be worth looking at...
Comment 20 Alexandre Oliveira 2005-07-14 17:43:06 UTC
*** Bug 109086 has been marked as a duplicate of this bug. ***
Comment 21 Peter Galiovsky 2005-09-05 19:00:12 UTC
OK, now my two cents...

After some years of occasional Windows/Linux dual-booting I finally switched to Linux this summer. I've tried maybe a dozen of different players. They had all kinds of bells and whistles but none was really good at what I think player should do right in the first place -- PLAYING MUSIC. This is a particulary bitter finding considering I switched over from Windows.

Unfortunately, amaroK is in the same league. Well, it is in a league of its own considering the bells and whistles. But considering its player capabilites...

I've created my usual gapless playback test suite. I ripped two consequent tracks from a continuous CD (a DJ mix set) and verified (both in wave editor and by listening) they are ripped correctly with no audio data missing or silence added. Then I encoded them into FLAC (1.1.2), MP3 (LAME 3.90.3), AAC (Ahead MP4 Encoder, LC) and Ogg Vorbis (Xiph.org 1.1.1 with impulse trigger profile). Again, I verified that a proper player (foobar2000) plays them fine, without any gaps or trimming.

With all the superlatives everywhere, developer photos on the web site and a 10/10 from Uncley Rodney, I fired up amaroK with great expectations...

OMG, even the WAVs didn't play gaplessly!

I'm not familiar with amaroK's internal structure, but judging from some comments here, it seems it opens a new stream along with every playlist advancement. Is this really necessary? Do CD players switch on and off on every track change? Why not just open a stream when a playback is started and close it only after it stops completely?

Moreover, one person here commented that it seems as if the workload caused by all the operations executed during a track change contributed to the gap. If this is really the case, why there is no decode ahead mechanism in effect? A proper player in my eyes should have sufficient amount of decoded audio data cached first -- even before the currently playing song comes to an end -- and only afterwards start changing all those fancy cover arts and everything else. Or is seeing track "goodies" more important than actually hearing the track itself?

Also, reading the file from over a network lenghtened the gap substantially in my case. Sometimes it took more than a second for the next song to start playing! Without a proper decode ahead implementation, there could be no gapless playback possible at all...

Thirdly, if both previous issued would have been solved, issues with gapless playback of MP3, AAC (and possibly other similar formats) would IMHO still remain. Both doesn't preserve the exact length of the original file and add additional silence at the beginning (encoder delay) and end (encoder padding) of the track. Only LAME encoded MP3 files and some AAC files in a MP4/M4A container have these values stored in the file. To offer true gapless capability, player has to be aware of this, read the values and skip appropriate portions of the track. (foobar2000 for Windows does this. See sources of its foo_input_std component for details.)

Any kind of crossfade plugin is NOT a solution. Crossfade plugins don't provide true gapless playback. They just guess (more or usually less succesfully) the amount of silence needed to be skipped. This often results in removing silence that should stayed or ignoring silence that should be removed...
Comment 22 Richard Neill 2005-09-05 21:26:26 UTC
Re #21, you might find my comments to bug 106353 are relevant. (i.e. concatenating ogg files). 

As for a workaround, you might try xmms. I know it doesn't do everything and it isn't amarok, but it does solve your immediate problem, and it *is* capable of playing successive oggs in a playlist gaplessly. 

[Also, I know it is O.T., but amarok is in good company: the iPod doesn't do gapless playback either!]
Comment 23 Jeff Mitchell 2005-09-06 20:34:13 UTC
Regarding the comments from Peter--

Unlike Winamp or XMMS, which contain built-in decoders for various types of files and use their own playback engine, amaroK uses backends (gstreamer, xine, helix, arts) to perform the audio decoding and playback.  That's why, for instance, some files can be played with some engines but not with others, depending on which capabilities you have compiled into the various engines.

This is a *good thing* for several reasons.  Probably the most important one, IMHO: it allows the amaroK devs to concentrate on doing what they do best -- making a kick-ass user interface with lots of great features, so that you can organize your music in a way that is second to no other player -- instead of having to concentrate on worrying about how to decode every type of audio known to folk, much less find and fix all the bugs that pop up (Winamp *still* fixes bugs in their mp3 decoder).  Let the Gstreamer folk worry about that.

Of course, this also means that you're limited by the capabilities of the backend engines.  For instance, one of the engines didn't used to support visualizations or crossfading (xine I think).  So, what if the engines don't support pre-buffering a stream, or simply have latency issues of their own?  Then you're stuck...because either you have to live with what the other projects provide to you, or you have to try to do it yourself, which is a huge undertaking.

I'm not trying to give a get-out-of-jail free pass to this problem...after all, I reported this bug, so it affects me too.  I'm simply trying to make you aware of the fact that the various backend engines are a good thing, but that it means that the solution to this may not be trivial, because of the capabilities of the various backend engines.  I don't know for sure, because I haven't hacked around amaroK code (or for that matter gstreamer, arts, xine...), but the best way to get this fixed is to put more votes on it and get it confirmed by popular vote, so that the devs will hunker down and take a serious look at what can be done.

Or, to fix it yourself :-)
Comment 24 Peter Galiovsky 2005-09-11 14:20:43 UTC
I appologize if I've sounded too harsh, but it just strickens me that any application in the seemingly purely practical Linux would sacrifice functionality for GUI. I well understand the pros (and cons) of using separate engines for playback. Perhaps this should be filed as a bug of xine or GStreamer -- I'm not sure as I haven't worked with either of these engines...

Meanwhile, xmms2 and MPD both look promising as they have no problem with gapless playback of "good" formats, MP3 plugins probably only need a (hopefully simple) patch.
Comment 25 Jeff Mitchell 2005-09-11 21:41:58 UTC
{comments withheld to avoid a flamewar on bugs.kde.org}  :-)
Comment 26 Peter Galiovsky 2005-09-11 21:47:14 UTC
:-) OK, once again I apologize. I wish all the best to amaroK. The GUI is really superb, it player part just lacks some features I consider essential. :-)

Hey, more voters for this bug! :-)
Comment 27 Rodney Gordon II 2005-09-13 00:22:14 UTC
I also am keeping my votes on this one. Gapless playback with amaroK would be heavenly... I went to MPD for a few months, and I am back with amaroK again now and feeling pretty good, despite no gapless playback..

I collect live sets/bootlegs of shows, and sometimes it is necessary to have gapless, so much so I just launch XMMS sometimes to play those..

Gapless IS important.. But I am not sure if any of the amaroK devs can do anything about it.. Or can they?

Is there any way to precache the content before a songchange and prebuffer the next song or anything?

I'd love to have gapless in amaroK. Please please please :)
Comment 28 Mark Kretschmann 2005-09-23 17:04:38 UTC
This is a wish.
Comment 29 Michael Pujos 2005-09-30 14:41:56 UTC
The problem is that the engines must support gapless playback.

Try to load a gapless ogg album in xine-ui and you get the same problems (gaps) than in amarok with the xine engine !

IMHO that is a shame not to have gapless playback yet ! It is rather important for a proper player.
Comment 30 Alexandre Oliveira 2005-10-14 07:58:40 UTC
*** Bug 114377 has been marked as a duplicate of this bug. ***
Comment 31 Mark Kretschmann 2006-01-17 18:10:55 UTC
1.4-SVN supports gapless playback with libxine 1.1.1 :)
Comment 32 Peter Galiovsky 2006-01-18 16:08:14 UTC
Happy to hear this :), however still some problems here. Checked out SVN, built, installed...

Tried two FLACs first. Indeed, there was no gap between tracks. Instead, a bit of the first one was missing at the end. :-)

Moreover, when I put a FLAC file at the end of the playlist and played it alone, in the moment when decoding of the next file should start (and did not, as there were no more entries in the playlist), there was an audible dropout.

I wanted to try this with WAVs as well, but for some strange reason, I was unable to seek in them. :-)

And I don't suppose the new gapless playback feautre also uses padding and delay info from LAME headers of LAME-encoded MP3 files for gapless MP3 playback? Playing two MP3s still produced a gap in between. (But this is probably an issue of the decoding engine itself and not amaroK...)
Comment 33 Mark Kretschmann 2006-01-18 16:52:42 UTC
On Wednesday 18 January 2006 16:08, Peter Galiovsky wrote:
> And I don't suppose the new gapless playback feautre also uses padding and
> delay info from LAME headers of LAME-encoded MP3 files for gapless MP3
> playback? Playing two MP3s still produced a gap in between. (But this is
> probably an issue of the decoding engine itself and not amaroK...)

No, it doesn't compensate for the padding.
Comment 34 madman 2006-07-08 09:41:52 UTC
Actually, this situation is not FIXED. It is anything but good. Not only Amarok is cutting a few hundred milliseconds off the beginning of a track, with xine engine and remote files (not radio streams - fixed length remote files) it cuts about a second from the end of the file.

Gapless playback? Forget about it. If needed, go to MPD. Amarok is getting so complicated and featureful, its developers forget about an important thing: it is meant to be a music player.
Does a hardware CD player cut beginning and end of a song? No
Does it make a pause between gapless tracks? No

Amarok also shouldn't.
Comment 35 Rodney Gordon II 2006-07-08 14:48:07 UTC
Agreeing with last poster, this seems like a dead end road.

I tried 1.4.0 and 1.4.1, amaroK seemed to do odd things with my gapless flac playback.. I am a live music trader, I have tons of flacs, and amaroK sadly just isn't cutting it. As last poster has mentioned, I just have moved on to MPD/GMPC.

I've given up on amaroK due to all the bugs and problems with the "engines" sure the interface is to die for but.. the main piece is STILL broken. Hell, seeking in flacs is still broken in 1.4.

Sigh. Sorry to go from amaroK, but I've no other choice.
Comment 36 Jeff Mitchell 2006-07-12 03:32:40 UTC
It's spelled Amarok.