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.

Does this happen every time when you play that certain track? What file-type is it? Does it come from local collection?

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.

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.

I can confirm this issue using Amarok 2.5.90 (Beta) for TrackGain at MP3 and FLAC files.

Not sure if the bug is influenced by lag on a system, however I was unable to reproduce after following the previous bug notes.

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

(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?

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.

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

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?

<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 ;)

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)

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.

Still an issue. Still annoying. Any progress?

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

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.

Just to update this bug again: I still hear it with gstreamer 1.4.5 and amarok 2.8.0.

(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?

(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?

It's Gentoo's current stable version: media-libs/phonon-gstreamer-4.7.2

(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

Probably right, I actually have both version 0.10.36 and 1.4.5 installed. Possibly, 1.4.5 was pulled by Qt 5.

A possibly relevant merge request was started @ https://invent.kde.org/multimedia/amarok/-/merge_requests/82

A possibly relevant merge request was started @ https://invent.kde.org/multimedia/amarok/-/merge_requests/99

Git commit 99b5bd4f38f7311a77ed132dcce869a2cbbc3382 by Tuomas Nurmi.
Committed on 10/07/2024 at 12:19.
Pushed by nurmi into branch 'master'.

Try harder to avoid volume spikes when ReplayGain changes from low to high

Gain was adjusted in slotNewTrackPlaying, which will be called only after
the new track has started playing, causing a volume spike of a second or so.
Try to avoid this by only doing gapless playback when the next track is
from the same album, and by setting gain a bit earlier in playback preparation
if possible.

Shouldn't affect any cases where ReplayGain is not available (= phonon-vlc)
or used.

M  +3    -0    ChangeLog
M  +51   -37   src/EngineController.cpp
M  +5    -0    src/EngineController.h

https://invent.kde.org/multimedia/amarok/-/commit/99b5bd4f38f7311a77ed132dcce869a2cbbc3382