Summary: | Crossfade issue with GStreamer engine, making fadein of new song volume jump | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Caveman <james-bond-is-007> |
Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mail, mono82, turnip |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Caveman
2005-03-29 04:28:07 UTC
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 ;) |