Bug 299461 - amarok: song starts playing before gain is adjusted
Summary: amarok: song starts playing before gain is adjusted
Status: CONFIRMED
Alias: None
Product: amarok
Classification: Applications
Component: Playback/Replay Gain (show other bugs)
Version: 2.8-git
Platform: Ubuntu Linux
: NOR normal
Target Milestone: 2.8
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-05 19:48 UTC by missive
Modified: 2016-06-29 15:50 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description missive 2012-05-05 19:48:13 UTC
I am using Replay Gain Mode -> Track

Previously, this has worked flawlessly. Since upgrading to Ubuntu 12.04 (Amarok 2.5.0 on KDE 4.8.2) there is a problem:

The song will start playing for just an instant before the gain is adjusted. So, for some songs where there is a large downward volume adjustment, the song will come on as a loud blast and then immediately adjust down to the proper level.


Reproducible: Always

Steps to Reproduce:
1. Set Amarok to Replay Gain Mode
2. Start playlist

Actual Results:  
Slight lag in gain adjustment. Only gets adjusted after song has already started playing.

Expected Results:  
Gain gets adjusted before any sound is played.
Comment 1 Myriam Schweingruber 2012-05-06 11:54:30 UTC
It would be nice if you could test a version as soon as it comes out.  Since you are using Kubuntu, you  can get Amarok through the kubuntu-backports-PPA quite fast.
Comment 2 Matěj Laitl 2012-05-16 21:05:56 UTC
Does this happen every time when you play that certain track? What file-type is it? Does it come from local collection?
Comment 3 missive 2012-05-17 00:52:07 UTC
It is not a particular track. This is between all tracks. Some are more noticeable, probably because of larger gain adjustment, but they all seem to have a delay of ~0.25 seconds between the track starting and the gain being adjusted. If the track starts off loud and there is a large gain adjustment, it can be quite a shock.

These are all tracks being played from the local collection. All are .ogg files with gain set using vorbisgain.
Comment 4 Daniel Faust 2012-06-13 19:05:49 UTC
Happens to me too. But it's hard to say since when because it's not always that noticeable.
I'm always using a very recent git snapshot.
It happens in TrackGain and AlbumGain mode likewise and with flac files, too.
Comment 5 Mathias Dietrich 2012-06-14 13:23:04 UTC
I can confirm this issue using Amarok 2.5.90 (Beta) for TrackGain at MP3 and FLAC files.
Comment 6 Kyle 2012-12-03 15:09:46 UTC
Not sure if the bug is influenced by lag on a system, however I was unable to reproduce after following the previous bug notes.
Comment 7 shaddowy2 2012-12-06 15:28:38 UTC
Happens to me only when using phonon-gstreamer, because only the gstreamer back-end seems to adjust the gain accurately. Every time I tried phonon-vlc, I didn't have the problem, but also no gain adjustment at all. 

Amarok version: 2.6
Phonon Gstreamer version: 4.7.0really4.6.2-0ubuntu1
Phonon VLC version: 0.6.0-1
Comment 8 Myriam Schweingruber 2012-12-07 09:05:00 UTC
(In reply to comment #7)
> Happens to me only when using phonon-gstreamer, because only the gstreamer
> back-end seems to adjust the gain accurately. Every time I tried phonon-vlc,
> I didn't have the problem, but also no gain adjustment at all. 
> 
> Amarok version: 2.6
> Phonon Gstreamer version: 4.7.0really4.6.2-0ubuntu1
> Phonon VLC version: 0.6.0-1

Harald, any ideas?
Comment 9 Matěj Laitl 2012-12-08 20:00:25 UTC
I can reproduce this, so there's a good chance that the cause will be tracked down once I find time.

Wild guess is that Phonon::MediaObject currentSourceChanged() (or stateChanged()) is emitted too late so that the adjustment is audible. Hard to solve with current async Phonon API IMO, but at least we should be able to receive currentSourceChanged() in tens of milliseconds, not hundreds.
Comment 10 Matěj Laitl 2012-12-09 10:26:04 UTC
Git commit ec9ac5628ccc76be603b253be3ee4278786dc4af by Matěj Laitl.
Committed on 09/12/2012 at 11:22.
Pushed by laitl into branch 'master'.

EngineController: remove xine work-arounds

thanks to Harald for pointing to them.

M  +0    -4    src/EngineController.cpp

http://commits.kde.org/amarok/ec9ac5628ccc76be603b253be3ee4278786dc4af
Comment 11 Matěj Laitl 2012-12-09 11:01:52 UTC
Okay, even with the patch above I can reproduce this. Note that in order to reproduce, the test file must not be the first one played, just put it into playlist under currently playing song. Further info:

phonon-gst 4.6.2: ~1s delay for applying replay gain
phonon-vlc 0.6.1 + vlc 2.0.3: no replay gain applied at all (does it support VolumeFaderEffect?), plays much louder that phonon-gst.

With test-file www.strohel.eu/ miscfiles/CD1%2003%20Reunion.mp3 (remove the space; -11 dB replay gain). Interestingly enough, when I do `amarok -d --debug-audio --nofork 2>&1 | grep -iC10 gain`, I get the following:

amarok: BEGIN: void EngineController::slotNewTrackPlaying(const Phonon::MediaSource&) 
amarok:   [EngineController] Previous track finished completely, updating statistics 
amarok:   [EngineController] slotTrackFinishedPlaying( KUrl("file:///home/strohel/music/mp3/Pink Martini/2009 Splendor In The Grass/06 But Now I'm Back.mp3") , 1 ) 
amarok:   BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) 
amarok:     BEGIN: void PlaylistInfoWidget::updateTotalPlaylistLength() 
amarok:     END__: void PlaylistInfoWidget::updateTotalPlaylistLength() [Took: 0s] 
amarok:     [Playlist::Model] Metadata updated for track "But Now I'm Back" 
amarok:   END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) [Took: 0s] 
amarok:   [lastfm] scrobble:  "Pink Martini" - "Splendor In The Grass" - "But Now I'm Back" source: 2 duration: 177 
QMap(("album", "Splendor In The Grass")("albumArtist", "Pink Martini")("artist", "Pink Martini")("chosenByUser", "1")("context", "")("duration", "177")("method", "Track.scrobble")("timestamp", "1355050502")("track", "But Now I'm Back")) 
amarok:   [EngineController] Using gain of -11.06 with relative peak of 0.410905 
PHONON-GST   Fading to 0.279898 
amarok:   BEGIN: void Context::ContextView::slotTrackChanged(Meta::TrackPtr) 
amarok:   END__: void Context::ContextView::slotTrackChanged(Meta::TrackPtr) [Took: 0s] 
amarok:   BEGIN: void RecentlyPlayedListWidget::trackChanged(Meta::TrackPtr) 
amarok:   END__: void RecentlyPlayedListWidget::trackChanged(Meta::TrackPtr) [Took: 0s] 
amarok:   BEGIN: void LabelsEngine::update(bool) 
amarok:     BEGIN: void LabelsEngine::fetchLastFm() 
amarok:     END__: void LabelsEngine::fetchLastFm() [Took: 0s] 
amarok:   END__: void LabelsEngine::update(bool) [Took: 0s] 
amarok:   BEGIN: void LyricsAppletPrivate::_trackDataChanged(Meta::TrackPtr) 
--
amarok:   BEGIN: void LyricsAppletPrivate::showLyrics(const QString&) 
amarok:   END__: void LyricsAppletPrivate::showLyrics(const QString&) [Took: 0.012s] 
amarok: END__: void LyricsApplet::dataUpdated(const QString&, const Plasma::DataEngine::Data&) [Took: 0.012s] 
"PulseSupport(2): Found PulseAudio stream index 30 for Phonon Output Stream {136dc0fc-e4c7-493b-8687-98515db62afd}" 
"PulseSupport(2): Found PulseAudio stream index 30 for Phonon Output Stream {136dc0fc-e4c7-493b-8687-98515db62afd}" 
PHONON-GST Stream changed to file:///home/strohel/music/mp3/M83/2011%20Hurry%20Up,%20We%27re%20Dreaming/CD1%2003%20Reunion.mp3 
amarok: [EngineController] slotMetaDataChanged() triggered by phonon, but we've already seen exactly the same metadata recently. Ignoring for now. 
Metadata ready, sending to zeitgeist 
void Phonon::MediaObjectPrivate::_k_currentSourceChanged(const Phonon::MediaSource&) 
amarok: BEGIN: void EngineController::slotNewTrackPlaying(const Phonon::MediaSource&) 
amarok:   [EngineController] Using gain of -11.06 with relative peak of 0.410905 
PHONON-GST   Fading to 0.279898 
amarok:   BEGIN: void Context::ContextView::slotTrackChanged(Meta::TrackPtr) 
amarok:   END__: void Context::ContextView::slotTrackChanged(Meta::TrackPtr) [Took: 0s] 
amarok:   BEGIN: void RecentlyPlayedListWidget::trackChanged(Meta::TrackPtr) 
amarok:   END__: void RecentlyPlayedListWidget::trackChanged(Meta::TrackPtr) [Took: 0s] 
amarok:   BEGIN: void LabelsEngine::update(bool) 
amarok:   END__: void LabelsEngine::update(bool) [Took: 0s] 
amarok:   BEGIN: void LyricsAppletPrivate::_trackDataChanged(Meta::TrackPtr) 
amarok:   END__: void LyricsAppletPrivate::_trackDataChanged(Meta::TrackPtr) [Took: 0s] 
amarok:   BEGIN: void WikipediaEnginePrivate::_checkRequireUpdate(Meta::TrackPtr)

...BUT the both "amarok:   [EngineController] Using gain of -11.06 with relative peak of 0.410905" lines appear really quickly after the song changes, to it is perhaps the phonon-gst's VolumeFaderEffect::setVolume() that is introducing the ~1s latency?
Comment 12 Harald Sitter 2012-12-09 11:46:39 UTC
<apachelogger> oh, it may be timing related
<apachelogger>   connect( m_media.data(), SIGNAL(currentSourceChanged( const Phonon::MediaSource & )),
<apachelogger>              SLOT(slotNewTrackPlaying( const Phonon::MediaSource & )) );
<apachelogger> alo phonon signals are dispatched in a queued manner, so by the time the slot function gets called gstreamer may already have been playing for an undefined number of milliseconds
<apachelogger> matej would know I guess
<apachelogger> also the solution there would be to pause, then volume fade, then play
<Mamarok> and people willblame us then that we pause
<apachelogger> you do not need to reflect this
<apachelogger> you already do it for bookmark stuff IIRC
<apachelogger> (there is a reason in that in phive the state progression internally will always be stopped-paused-playing ^^)
<apachelogger> on general principle settings that ought to be applied before the first sample is played should be done by going to paused and then to whatever state that the user requested

until that behavior is implemented I don't think this will get any better :P
it really does not matter how quickly text gets printed as we are talking here about 2 concurrent threads. pgst's volumefader is using a core gstreamer element for volume control, it quite literally just sets the volume property on that element when you call setVolume so unless samples have already been passed through the element with a different volume this should be more or less instantaneous.

also regarding the question of whether pvlc does not support it:
http://community.kde.org/Phonon/FeatureMatrix
also in general I think you should be using MediaNode::isValid() more ;)
Comment 13 Matěj Laitl 2013-04-27 08:39:13 UTC
This cannot be a regression, there is simply no way to do both gapless playback *and* precise (not delayed) gain adjustment at the same time with current Phonon, AFAICS. Currently we've chosen to do the gapless.

Harald, I've been thinking how to solve this for Phonon5 with no particular idea.. (one way could be to allow to chain effects on Phonon::MediaSource, but that seems convoluted)
Comment 14 CatKiller 2013-09-05 17:40:28 UTC
Any motion on this? It still happens in 2.7.0 and it's really annoying. I would gladly sacrifice a few milliseconds of pause time to make Amarok behave properly with ReplayGain.
Comment 15 CatKiller 2014-06-27 18:39:47 UTC
Still an issue. Still annoying. Any progress?
Comment 16 Tim 2014-07-08 17:38:32 UTC
I am new to Amarok(was switching from Banshee) and love everything about it except the delay with gain adjustment is very annoying...the short softness is not too horrible but if its being adjusted down the sudden boom can be...heh
Comment 17 Daniel Vrátil 2014-08-12 21:26:05 UTC
We are almost sure that this is a gstreamer problem with VolumeFaderEffect taking too much time to "kick in". I tried changing the code to directly set the volume and it works immediatelly, and I couldn't find any place in Phonon GStreamer that would be causing the delay.

This seems to happen with GStreamer 1.0 too.
Comment 18 Tobias Leupold 2015-05-31 10:40:02 UTC
Just to update this bug again: I still hear it with gstreamer 1.4.5 and amarok 2.8.0.
Comment 19 Myriam Schweingruber 2015-05-31 11:17:52 UTC
(In reply to Tobias Leupold from comment #18)
> Just to update this bug again: I still hear it with gstreamer 1.4.5 and
> amarok 2.8.0.

Which exact phonon-backend-gstreamer version do you use?
Comment 20 Myriam Schweingruber 2015-05-31 11:18:06 UTC
(In reply to Tobias Leupold from comment #18)
> Just to update this bug again: I still hear it with gstreamer 1.4.5 and
> amarok 2.8.0.

Which exact phonon-backend-gstreamer version do you use?
Comment 21 Tobias Leupold 2015-05-31 11:23:04 UTC
It's Gentoo's current stable version: media-libs/phonon-gstreamer-4.7.2
Comment 22 Myriam Schweingruber 2015-05-31 18:40:36 UTC
(In reply to Tobias Leupold from comment #21)
> It's Gentoo's current stable version: media-libs/phonon-gstreamer-4.7.2

I guessed as much: that version is still using the gstreamer 0.10.x libraries, you need at least version 4.7.80 for the gstreamer 1.x libraries
Comment 23 Tobias Leupold 2015-05-31 19:05:18 UTC
Probably right, I actually have both version 0.10.36 and 1.4.5 installed. Possibly, 1.4.5 was pulled by Qt 5.