Version: (using KDE KDE 3.3.2) Installed from: Debian testing/unstable Packages Compiler: gcc (GCC) 3.3.5 (Debian 1:3.3.5-12) OS: Linux When next song in playlist starts to fadein I am finding this first few seconds (around 2-4) the volume of the song is very low (about the volume I would except to see at the very start of the fadein), after the few seconds the volume jumps backup to a normal level and the song continues to play correctly instead of fading smoothly. I believe is a crossfade issue not a fadein issue as turning crossfade off stops the problem. I have also found that when the next song starts playing the time played counter jumps to 4seconds and says there for around 2-4 seconds. It then continues as it should right after the volume jump, which make me thing is has something to do with it. Increasing crossover time to say 10seconds makes no difference at all, and neither does increasing the length of fadein. I have however noticed that the first song I play after starting amarok seems to fadein perfectly, which seems to say its go something to do with the crossover. I have only had this problem since 1.2.2, if I go back to 1.2.1 the whole fadein/fadeout/crossover works prefectly. I have had problems with 1.2.2 1.2.2-CVS up to around 3days ago (that was the last time I tested it) and I am also having the same issue with 1.2.3 released today. These 2 messages below seem the most interesting of what i get in my console dump (process:24162): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:24162): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed Seem interesting, however I have no idea if they have anything to do with my problem. I have also spoke to people in the IRC channel and a few of them are having the same issue. START CONSOLE DUMP ------------------------ caveman@biocorporation:~$ amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: [controller] Crossfading to next track... amarok: [controller] Loading URL: file:/data/my_music/Albums/Avril%20Lavigne/Under%20My%20Skin/Avril%20Lavigne%20-%20Slipped%20Away.mp3 amarok: BEGIN: virtual bool GstEngine::load(const KURL&, bool) amarok: [Gst-Engine] Loading url: file:/data/my_music/Albums/Avril%20Lavigne/Under%20My%20Skin/Avril%20Lavigne%20-%20Slipped%20Away.mp3 amarok: BEGIN: InputPipeline::InputPipeline() amarok: END__: InputPipeline::InputPipeline() - Took 0.01s amarok: END__: virtual bool GstEngine::load(const KURL&, bool) - Took 0.05s amarok: BEGIN: virtual bool GstEngine::play(unsigned int) amarok: BEGIN: void EngineSubject::stateChangedNotify(Engine::State) amarok: [virtual void amaroK::StatusBar::engineStateChanged(Engine::State)] Line: 123 amarok: BEGIN: virtual void ContextBrowser::engineStateChanged(Engine::State) amarok: END__: virtual void ContextBrowser::engineStateChanged(Engine::State) - Took 0s amarok: END__: void EngineSubject::stateChangedNotify(Engine::State) - Took 0s amarok: END__: virtual bool GstEngine::play(unsigned int) - Took 0.01s amarok: BEGIN: virtual uint GstEngine::length() const amarok: END__: virtual uint GstEngine::length() const - Took 0s amarok: BEGIN: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) amarok: END__: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) - Took 0.02s amarok: BEGIN: virtual bool CurrentTrackJob::doJob() amarok: END__: virtual bool CurrentTrackJob::doJob() - Took 0.02s amarok: [ThreadWeaver] Job completed: CurrentTrackJob. Jobs pending: 0 amarok: BEGIN: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) amarok: [Gst-Engine] received tag 'Title': Slipped Away amarok: [Gst-Engine] received tag 'Artist': Avril Lavigne amarok: [Gst-Engine] received tag 'Album': Under My Skin amarok: END__: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) - Took 0s amarok: BEGIN: static void GstEngine::newPad_cb(GstElement*, GstPad*, int, InputPipeline*) (process:24162): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:24162): GStreamer-WARNING **: pads don't accept old caps. We assume they did though amarok: END__: static void GstEngine::newPad_cb(GstElement*, GstPad*, int, InputPipeline*) - Took 0.13s amarok: BEGIN: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) amarok: END__: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) - Took 0s amarok: BEGIN: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) amarok: END__: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) - Took 0s amarok: [static void GstEngine::eos_cb(GstElement*, InputPipeline*)] amarok: BEGIN: void GstEngine::endOfStreamReached() amarok: An input pipeline has reached EOS, destroying. amarok: BEGIN: void GstEngine::destroyInput(InputPipeline*) amarok: [Gst-Engine] Destroying input pipeline. amarok: BEGIN: InputPipeline::~InputPipeline() amarok: [Gst-Engine] Destroying input bin. (process:24162): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed amarok: END__: InputPipeline::~InputPipeline() - Took 0s amarok: END__: void GstEngine::destroyInput(InputPipeline*) - Took 0s amarok: END__: void GstEngine::endOfStreamReached() - Took 0s amarok: [Gst-Engine] XFade-in finished. amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0
I get this too.
Also (sorry, I should have said this in the previous comment), it is possibly related to bug #99570.
I also experience this bug. I can confirm that when starting a new song, the counter will jump and stick at some time (~4-6 s), and once that actual time in the song is reached, the volume will jump up and be normal for the rest of the song. I've been using amaroK 1.2.3 almost since it was released, but have only noticed this problem after rebuilding it today. In that time, I have upgraded to gstreamer 0.8.9, so perhaps this is a result of some change in gstreamer from previous versions?
I should also add that I also upgraded to gstreamer-plugins 0.8.8 at the same time, so the bug could instead be related to that.
I did some experiments with chnaging xfade length (even to 25 s), what I found was that, supposedly: 1) the message "(process:20150): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed" is not related to any audible gaps or that volume jump. It is some bad amarok<->gst interaction, although noted as "critical" by gst 2) there is a gap before a new song starts, independent whether xfading or playing continously - its length slightly changes, but this gap length correlates quite good with the following timing - "amarok: BEGIN: static void GstEngine::newPad_cb(GstElement*, GstPad*, int, InputPipeline*) (process:20162): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:20162): GStreamer-WARNING **: pads don't accept old caps. We assume they did though amarok: END__: static void GstEngine::newPad_cb(GstElement*, GstPad*, int, InputPipeline*) - Took 0.27s" this time is typically between 0.2x - 0.5x seconds. This "sounds" like a bug in gst-engine part. 3) the inital low volume and that sudden increase is still mysterious (to me, as to most other folks here). It really might be a gst bug. On the other hand, I see these fade-ins and fade-outs as unneeded, at least considering the trouble they have created. What, IMO, most people want is a nice xfade, which could even be a simple parallel playback, since most songs already have some characteristic intro and outro phase.
*** Bug 99570 has been marked as a duplicate of this bug. ***
Any news on getting this sorted out? It has been awhile. I don't believe this problem is related to gstreamer, as dropping back to 1.2.1 fixes the program. Caveman
This problem doesnt appear to affect FLACs or OGG VORBIS files. It seems related to the MAD gstreamer plugin.
On Friday 10 June 2005 18:52, theboywho@ruddyperl.com wrote: > ------- This problem doesnt appear to affect FLACs or OGG VORBIS files. It > seems related to the MAD gstreamer plugin. Interesting observation. So it is indeed a regression in this plugin, since it used to work until a certain version. Unfortunately I can't think of a workaround :(
Can we get it fixed in the plugin then?
By plugin are we talking a plugin in amarok or a gstreamer plugin? Because I fail to see how it can be a gstreamer plugin, I just moved back to 1.2.1 and the problem goes away and thats without making ANY gstreamer changes. Either way a fix would be good. Or maybe a whole new way of dealing with fade in/out and crossover ? Caveman
Just to say also experience this amarok 1.3b2 gstreamer 0.8.9 gst-plugins-mad 0.8.8
I, too, have experienced this. gstreamer 0.8.10 gst-plugins-mad 0.8.10 and amarok 1.3b2. I normally use arts engine but decided to try gst since arts engine can't handle l365 streams.
*** Bug 108881 has been marked as a duplicate of this bug. ***
NOTE: xine-engine now supports crossfading (in svn). Works rather nicely.
I don't mean to be being rude here, but when is this bug going to be fixed? I fully understand that the developers have plenty of responsibilities doing various weird and wonderful things with amaroK (which is fantastic, by the way), but this has been around for ages now with next to nothing done. Clearly plenty of people are experiencing this problem, and clearly plenty of people want it fixed. There are 184 votes here, and 231 votes on bug 96680 which is most probably related. Making usability enhancements to the interface is all well and good, but for the people affected, this is a far more important issue. I bet if one of the core developers was affected by this bug it would be fixed pretty quickly. Markey said that it was a problem with MAD. IF that is the case (which I am not sure about given comment 11), amaroK developers should work with the MAD people to resolve the issue. If NOT, they should be fixing this in the amaroK source. I think the starting point would be to find out what really is the cause of the problem -- I expect a comparison between the 1.2.1 source and the current source should make the answer apparent (but I don't pretend to be a C++ programmer who knows whether that's true or not). At the end of the day, I, and a whole lot of other users would be made really, really happy if this issue was fixed. Please listen to us. End of rant.
Everyone affected by this bug, please check out http://bugs.kde.org/show_bug.cgi?id=96680#c7 and report whether you still have a problem. I'd report my findings myself, except I just moved from Gentoo (where I was affected) to Ubuntu. Latest SVN works great for me but I don't know whether that's anything new or not... Cheers : )
*** Bug 112272 has been marked as a duplicate of this bug. ***
Crossfading has been removed from GStreamer engine starting with amaroK 1.3.1. So the issue is "fixed", one could say ;)