Side effects when changing Music-Volume with GUS emulator (w/o gus patches) #1729
Comments
|
I had a closer look at this and the reason (at least for windows user) behind this behavior is how the volume in case of the GUS emulation (timidity) is set: i_sdlmusic.c static void UpdateMusicVolume(void)
{
int vol;
if (musicpaused)
{
vol = 0;
}
else
{
vol = (current_music_volume * MIX_MAX_VOLUME) / 127;
}
Mix_VolumeMusic(vol);
}The Setting the music volume in doom with active GUS to max again, increases the volume to almost the full potential of the master volume (120 instead of 128, due to the above seen calculation): Unfortunately, this is never reset back to max volume again when switching to anything else than GUS. That means, once you set the sdl-device to GUS and make changes to the music slider in-game, it will impact the sound mixer even if you switch to another sdl-device later on. And additionally, without modifying the mixer in windows directly, it will reduce your max volume by at least 8 points. Other sdl-devices don't seem to rely on changing the mixer settings. Now knowing how to work around this easily in the windows mixer settings, my question would be if this still should be fixed. If so, a possibility could be to set the Mix_VolumeMusic to MIX_MAX_VOLUME when initializing anything different than the GUS emulator. |
This looks like a bug in SDL_Mixer. I think |
This. We shouldn't have to care about the underlying driver, that 's the whole point of SDL_Mixer. |
|
Just curious, are you using the GUS patches and pointing Chocolate Doom to the correct folder? (Per instructions here) The reason I ask is because this sounds a whole lot like the known issue where midi volume affects application volume when using native Windows midi through SDL Mixer. When you ask SDL Mixer to play a midi it will attempt to use Timidity first but if that fails it will next try native midi. Could that be happening here? |
Thanks for that info! I did indeed not set the path so far, I saw in the code there is an autoload function that correctly detected my steam folder and thought that would do the trick, but upon closer inspection and debugging, it didn't find anything there because I hadn't installed the bfg edition.... 😀 Ouch!
Yes, I think that is what happened here. So when following the instructions linked above, it all works correctly and it doesn't affect the windows mixer any longer. Do you happen to have a link to this known issue? Then I would close this one as a duplicate. Now one last thing I want to mention: When going to the actual native midi setting in the sound options, it seems to choose a different device internally: i_sound.c InitMusicModule: Since the music_sdl_module seems to introduce the issue, couldn't GUS default on the win_module instead when not detecting any patches? |
I think we should exit the program with an error message if GUS patches are not found. Otherwise it will cause confusion. |
Instead of exiting, would also be disabling of sound (or specifically music) be an acceptable action in those scenarios? |
|
Do we want to do something about this for the 3.1.1 release? |
Unless someone else wants to open a PR, I would like to give it some more time to better understand the code and behavior before trying to change something. 😉 I just found that when setting an incorrect / nonsense gus path (e. g. "test"), it would behave like I would expect it: No music, but sfx and no impact to the Windows Mixer settings.. I just still don't understand completely, why that is. |
|
Something like this perhaps? Diffdiff --git a/src/i_sdlmusic.c b/src/i_sdlmusic.c
index 313ca63c..39e2f16b 100644
--- a/src/i_sdlmusic.c
+++ b/src/i_sdlmusic.c
@@ -177,6 +177,8 @@ static boolean SDLIsInitialized(void)
return Mix_QuerySpec(&freq, &format, &channels) != 0;
}
+static char sdl_mixer_disable_nativemidi[] = "SDL_MIXER_DISABLE_NATIVEMIDI=1";
+
// Initialize music subsystem
static boolean I_SDL_InitMusic(void)
{
@@ -208,6 +210,12 @@ static boolean I_SDL_InitMusic(void)
}
}
+ #ifdef _WIN32
+ // Never let SDL Mixer use native midi on Windows. Avoids SDL Mixer bug
+ // where music volume affects global application volume.
+ putenv(sdl_mixer_disable_nativemidi);
+ #endif
+
// Initialize SDL_Mixer for MIDI music playback
Mix_Init(MIX_INIT_MID);This should prevent SDL Mixer from using native midi on Windows entirely. |
I did just test it and I think thats a good solution! 👍 The impact on the windows mixer is gone and in case the path is not set (correctly), the user would notice with the Music missing but the SFX still playing. |
|
@mikeday0: Since it is imho a good way to solve it, are you planning to open a PR with that diff shown above? 😉 |
Done! Thanks for the reminder. |
Uh oh!
There was an error while loading. Please reload this page.
Background
Version of Chocolate Doom: 3.1.0
Operating System and version: Windows 10
Game: Doom, Heretic, Hexen, Strife
Any loaded WADs and mods (please include full command line): -
### Bug description:
Observed behavior:
Both SFX and Music Audio remain either off / or are reduced by the amount in step 2) when GUS Emulator was active.
Expected behavior:
SFX and Music Settings should work normally when switching from GUS to something else, no hidden offset or disabling.
The text was updated successfully, but these errors were encountered: