We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Created attachment 3263 [details]
Test program showcasing this bug

As the subject says, Mix_FadeOutChannel() does not save the channel's previous volume in the internal _Mix_Channel fade_volume_reset field. This is caused by unreachable code in Mix_FadeOutChannel() which only saves the volume is the fading status is MIX_NO_FADING, right after the function itself has set said status to MIX_FADING_OUT.

As of this writing the culprit is mixer.c:1160 -- see https://hg.libsdl.org/SDL_mixer/file/85df7eea1ea3/mixer.c#l1160 .

As a result, the fade_volume_reset field is always SDL_MIX_MAXVOLUME *unless*, in theory, the volume has been set prior to calling Mix_FadeInChannelTimed(), which from a cursory glance at the code appears to always save the previous volume in fade_volume_reset.

In practice this means that without that prior step, after fading out a channel that's not at 100% volume and playing on it again, the sound sample will be played at 100% volume, which can prove inconvenient in some cases.

This issue currently applies to both the latest release (2.0.2) and the Mercurial tip.

Attached a small test program showcasing this bug. Upon launching it, it'll play a looping sound at low volume. Pressing space once will fade out the channel, and pressing it again will play the sound again without manually restoring the volume, which is back to SDL_MIX_MAXVOLUME.

It's worth noting that this appears to have been introduced while trying to fix bug #790: https://hg.libsdl.org/SDL_mixer/rev/d842a759e68a