Ok, it does appear that it is that simple.
In principle this (even the non-update case) results in volume jumps,
so maybe we'll want gradual gain change...
Notably, i thought we'd always seek if the pipeline
was already operating on the same URL as the new one,
but apparently only for adjacent songs?
The magic: if EBU R 128 loudness normalization is enabled,
just insert `volume` GST element into the pipeline
(where ReplayGain would be inserted) and configure it.
We currently don't support changing said gain after the pipeline
was created. We might need to, though, for a number of reasons.
This is a bit of a gotcha, there should be a point (where we seek?)
where we'd be able to change said gain, but for now this is a simple[r]
stop-gap fix.
The idea is that Integrated Loudness is an integral part
of the song, much like knowing it's beginning / ending
in the file, and we must handle it the exact same way,
and pipe it through all the way.
At the same time, `EngineBase` knows Target Level (from settings),
and these two combined tell us the Gain needed to normalize the
Loudness of the particular Song (`EngineBase::Load()` does that).
So the actual backend only needs to handle the Volume.
We don't currently support changing Target Level on the fly.
We don't currently support changing Loudness-normalizing Gain on the fly.
This does not handle the case when the song is loaded from URL
and thus the EBU R 128 measures, that exist, are not nessesairly correct.
This improves the performance of the analysis (by 2x!),
by offloading non-`libebur128`-computations (i.e. decode-convert)
to a separate thread, thus reducing walltime.
The most juicy bit!
This is based on Song Fingerprint Analysis,
but here we must know the actual song, and not just the file.
The library supports only interleaved S16/S32/F32/F64,
so we must be sure we insert `audioconvert` into pipeline.
One point of contention here for me, is whether we should
feed the frames to the library the moment we get them
in `NewBufferCallback`, or collect them in a buffer
and pass them all at once. I've gone with the former,
because it seems like that is not the worst choice:
https://github.com/strawberrymusicplayer/strawberry/pull/1216#issuecomment-1610075876
In principle, the analysis *could* fail,
so we want to handle that gracefully.
If "about-to-finish" was emitted before the preload time was reached, we never set the next uri, so gapless playback was broken.
Make sure to always set the next uri, and increase preload gap from 5 to 8 seconds.
When the audio bin failed to initialize, we tried to disconnect signals and probes after the audio bin was already freed.
Instead, free the audio bin in the destructor after disconnecting signals and probes.
Fixes#1133 and #1123
Jonas Kvinge
Roman Lebedev