Volume discontinuity on fade out

[ch3pjw]

When pyamp does a fade out (usually on exit, but can be triggered by running player.fade_out()), the volume gets set immediately to a lower level, from where the fade out proceeds. This is kind of intermittent in that sometimes I don't notice it, but it happens most times.

Increasing the fade out time does not have an effect. It does not seem like the fade is happening too quickly, because after the initial jump the fade takes as long as expected.

Zaheer Merali thinks it could be a bug with the rather old gstreamer that we're currently using, so I'm working on a local branch to update it.

Here's a copy of an email he sent me:

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#developing-uninstalled-gstreamer

http://linux.die.net/man/1/yum-builddep

ensonic (Stefan Kost) is the guy that did GstController. I would try your code under 1.2 before contacting him. His email is: ensonic@hora-obscura.de

Zaheer

[ch3pjw]

I now have a vaguely working python3/asyncio/gobject introspection/gstreamer1.0 branch, which is heading towards building the same pipeline (it's missing the controllers at present) and seeing if the bug still persists. See 72f40ea.

[ch3pjw]

I have a working hack of a solution for this. The problem stems for control points applying to a track permanently. That is, when the control points have been defined, seeking around in the track will always yield the same parameter values at that position. So, when we add a control point to fade to zero at a certain point, we're currently adding a ramp down from full volume at the start of the track. Therefore, the further we are from the start, the harsher the discrete jump in volume when the new, zero volume, control point is added.

My quick hacky solution for this is to add a control point at 'now' with the current volume, when we start the fade, and one at zero at the end of the fade. However, we have two problems yet to address: 1) I don't know how to get the current value for volume from the controller (and therefore it's unmapped value, because there seems to be some random scaling going on...) 2) I don't know how to remove control points once they've been processed - that is, we don't want someone changing volume (which is also interpolated) to seek backwards in their track and find that all their volume changes get replayed!

There must be APIs for doing this kind of thing, but so far they're not proving obvious to me!

[ch3pjw]

This is now fixed on the python3 branch, but not unit tested.