No Music + Weird Sound Pitching since 5.6

[drivetheory]

Background

Version of Crispy Doom: 5.6+

Operating System and version: Win7 SP1 (x64)

Game: (Doom/Heretic/Hexen/Strife/other) Doom

Any loaded WADs and mods (please include full command line): doom.wad

Sound Card: Creative Sound Blaster X-Fi Titanium Fatal1ty

Bug description

Observed behavior: Crispy Doom v5.6+ Sound effects: "Digital sound effects" causing sounds to be high pitched and sound very strange. Crispy Doom v5.6+ Music: "OPL (Adlib/Soundblaster) Chip Type: OLP2/OPL3" causes no music to be heard, however, selecting "GUS (emulated)" allows music to play correctly

Expected behavior: Proper sound and music as experienced in Crispy Doom version 5.5.2

[SoDOOManiac]

Check your soundcard sample rate and snd_samplerate in crispy-doom.cfg, what are the values?

[fabiangreffrath]

Please check if one of the measures outlined here helps: https://github.com/fabiangreffrath/crispy-doom/wiki/FAQ

[drivetheory]

NOTE: I downloaded Chocolate Doom 3.0.0 and it functions properly.

@Zodomaniac The sound sample rate is set to 44100 in both the crispy-doom.cfg as well as the sound card properties.

@fabiangreffrath I checked the FAQ, saw the link to the SDL Wiki, not sure where to modify the environment variable "SDL_AUDIODRIVER" specified, or if it is relevant given what I describe below. Also, if i set "use_libsamplerate" to "0" in the config sound effects cut out and do not fully play.

I noticed that in Chocolate Doom "SDL2.DLL" is v2.0.5.0 and "SDL2_mixer.dll" is 2.0.1.0 If i replace these 2 DLLs in Crispy Doom with the versions from Chocolate Doom the sound effects sound correct and the music plays. If i replace these 2 DLLs (plus "libmad-0.dll") in Chocolate Doom with the ones from Crispy Doom ("SDL2.DLL" v2.0.10.0 & "SDL2_mixer.dll" 2.0.4.0) Chocolate Doom experiences the problems I describe.

Hope this extra information i gained from testing a little bit ago helps.

[fabiangreffrath]

Yes, it shows that this is solely an SDL issue and nothing that could be fixed in the source port. To be extra sure, could you please download a Choco daily build and see if you experience the same issues?

[drivetheory]

@fabiangreffrath just downloaded and tested "chocolate-doom-20190910-win32". in this build the sound effects cut out before they finish playing and there is no music. the pitch of the sound is normal, so i opened the CFG and changed "use_libsamplerate" from 0 to 1 and that created the high pitch sound effects

[SoDOOManiac]

@fabiangreffrath , btw, what is libsamplerate_scale 0.650000?

[fabiangreffrath]

It's described in the source:

// Scale factor used when converting libsamplerate floating point numbers
// to integers. Too high means the sounds can clip; too low means they
// will be too quiet. This is an amount that should avoid clipping most
// of the time: with all the Doom IWAD sound effects, at least. If a PWAD
// is used, clipping might occur.

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/i_sdlsound.c#L82

[fabiangreffrath]

Closing as this is an SDL issue. Updated the Wiki with some more hints, hope that helps.

[drivetheory]

adjusting "libsamplerate_scale" from "0.99" all the way down to "0.01" does not stop the sounds from cutting out before they finish playing. also, there is still no music is playing at all.

will post this problem over at bugzilla.libsdl.org

[fabiangreffrath]

You could use the SDL libraries from previous Crispy or Choco releases. That's usually not a problem, I have heard of a lot of users who do this to mitigate problems with newer SDL versions.

[SoDOOManiac]

StasBFG discovered that this issue is actually caused by 5.1 speaker configuration that the current SDL2 version doesn't handle correctly but the SDL2 v2.0.5/SDL2_mixer v2.0.1 from Crispy 5.1 did.

[drivetheory]

@Zodomaniac Interesting information, I am running 5.1 so that's actually a bit of good news.

@fabiangreffrath
I posted a bug report a few days ago, hopefully if some more knowledgeable people add to the description it might get some attention. https://bugzilla.libsdl.org/show_bug.cgi?id=4799

[SoDOOManiac]

@drivetheory @fabiangreffrath I have come up with the solution to this problem which gives fluidsynth support as a bonus. crispy-doom-DLL-fix-pack.zip

[fabiangreffrath]

I have added the 5.1 surround -> 2.0 stereo idea to the FAQ in the wiki.

[drivetheory]

changing my speaker layout to stereo only introduces different problems in 5.6 and newer, music only comes from the right speaker as well as this creates a warbling effect on the sound effects and the music. however, changing my speaker layout to stereo has no negative effects on previous versions older than 5.6 which use the older DLLs.

[SoDOOManiac]

@drivetheory have you tried my DLL pack?

[drivetheory]

@Zodomaniac just tried your DLL fix pack in v5.6.1 and all sound effects and music play correctly with my speaker setup as 5.1, 24-bit, 96KHz.

[SoDOOManiac]

@Altazimuth could you please share your experience on resolving this in Eternity Engine after transition to SDL 2.0.10?

[Altazimuth]

Ultimately a large amount of EE's issues w/ SDL2 sound after 2.0.7 (I believe that was the version at least) was to do with audio drivers and playback formats. Ultimately I plonked the following in main

#if (EE_CURRENT_PLATFORM == EE_PLATFORM_WINDOWS)
   if(I_IsWindowsVistaOrHigher())
      SDL_setenv("SDL_AUDIODRIVER", "wasapi", true);
   else
      SDL_setenv("SDL_AUDIODRIVER", "winmm", true);
#endif

and then made it so there were two audio players: one for 16-bit signed integer audio, and one for single precision floating-point audio. You cannot assume that SDL_mixer will actually use the format you want to at this point, so Eternity now uses regular SDL to query this stuff before starting mixer up proper.

Ultimately it'd be nice to eliminate support for 16-bit signed int audio but it stands for the moment.

Important to note: Before WASAPI the string was "directsound" if memory serves. WASAPI only supports float audio and was made the default in 2.0.7, so you have to manually set the Windows driver to be DirectSound otherwise everything ends up all wonky.

[SoDOOManiac]

@Altazimuth thanks a lot! Players are requesting the sound fix for 5.1 in Crispy Doom on Doomworld forums and recalling your solution, that's why I decided to invite you to the thread here.

[Altazimuth]

Ah, no problem. My code should make an OK basis but does use a fair bit of C++isms, so will probably need a bit of expanding out to be less metaprogrammingy. Less templates and more void * or however that is to be dealt with. 5.1 fixes relied on knowledge of the number of channels and such. An SDL_AudioSpec called audio_spec is used for that, which EE sets the value of with the function I_GenSDLAudioSpec. Mix_OpenAudio can't be trusted to give you quite what you need, and I preferred using SDL_OpenAudio then closing again to using Mix_QuerySpec.

[putridpete]

I made a small discovery regarding this issue.

I'm on Windows 10 Pro x64, and I use a pair of 7.1 headphones. Obviously I was experiencing the issue in Chocolate Doom, Crispy Doom, Doom Retro and even with the port fabiangreffrath made recently called Woof.

What made the issue go away in all of the aforementioned ports for me, was to enable Windows Sonic. In order to do that, simply right click the speaker icon in your taskbar, select spatial sound and enable Windows Sonic. Alternatively, you can do it by going to Control Panel > Hardware and Sound > Sound > Right clicking your preferred sound device > Properties > Spatial Sound and selecting Windows Sonic.

I still had to use the Old DLL pack provided by Zodomaniac for Crispy and Choco, however. Despite the sound now working correctly, I noticed that music from music packs would stutter at the start of tracks and during a loop. This is a different issue altogether and it has been reported in Chocolate Doom's issues here.

Another oddity I noticed is that Crispy Doom's SFX sound seem quieter than Chocolate Doom after having enabled Windows Sonic, but nothing that presents any serious issues. I just had to crank up the volume in-game.

Anyway, hope this proves useful in any way.

[fabiangreffrath]

Is this still an issue with the 5.8.0 release?

[putridpete]

The issue is still present for me in 5.8.0 if I disable Windows Sonic for Headphones while using my 7.1 Headphones. Enabling Windows Sonic or switching to my stereo speakers fixes the issue.

[fabiangreffrath]

Thanks for the feedback. Given how fragile this is on Windows, I have now idea how I could mitigate the issue from the source port's side.

[drivetheory]

am now outta work and at home to test 5.8.0.

just a heads up though, "crispy-doom-setup.exe" gets quarantined by Microsoft Security Essentials as "Program:Win32/Unwaders.A!ml".

will post back the rest of my results shortly

[drivetheory]

My sincerest apologies for my lack of thoroughness previously, during testing this time around i discovered i had an old install of kode54's BASSMIDI installed... from YEARS ago... that i completely forgot was even installed... which lead to the previous testing results. this time around such software has been uninstalled. I'm sorry.

This weekend I did much more extensive testing than previously. I re-downloaded every single version of Crispy Doom available in github that doesn't need to be compiled, v5.4 to 5.8. From what I can determine the problem affects all the available versions of Crispy Doom i could download including versions before 5.6 (and partially affects Chocolate Doom 3.0.0).

Chocolate Doom 3.0.0 sounds correct using OPL, provided that the in-game volume sliders are not touched. For Crispy Doom 5.4 to 5.8, i could never get it to sound correct using OPL. Chocolate & Crispy exhibit the same behavior using GUS & Native MIDI (sound effects are quiet, music sounds normal, use of in-game volume sliders casues same problems described below). Some anomolies and further details were discovered during testing and are also described below.

The problem exists whether i am using my PCIe Sound Blaster X-Fi card (5.1, 24-bit, 96KHz), my motherboard's Realtek HD audio chip (stereo, 24-bit, 48KHz), or the headphone port of my Blue Yeti USB microphone (stereo, 16-bit, 44.1Khz) so it is not explicitly related to a 5.1 speaker setup as previously suspected.

Please forgive me for my inability to properly articulate what i am hearing except that it's almost as if the sounds and music are distorted, or are playing too slowly, or at the wrong sample rate, or something... I have recorded my desktop with the doom window to an MP4 file using OBS. https://www.dropbox.com/s/zprvl7vqom7kmmb/Chocolate%203.0.0%20vs%20Crispy%205.8.0.mp4?dl=0 The file is 1280x720, 320Kbs audio, 1 minute long and 68MB in size. the first 30 seconds i open chocolate doom 3.0.0 setup, show the sound settings, and then launch chocolate doom to the menu screen so the sounds can be heard. the second 30 seconds i open crispy doom 5.8.0 setup, show the sound settings, and then launch crispy doom to the menu screen so the sounds can be heard again. i don't know how to describe the difference between what is heard in chocolate vs crispy doom better than i describe previously so i am hoping when you hear what i hear it will create a moment of realization in you and become be glaringly obvious to you what is happening. fingers crossed.

i did notice a very strange behavior that happened only once while testing that i could not reproduce, crispy sounded distorted, i closed crispy and ran chocolate and then chocolate sounded distorted. so i closed chocolate and reopened chocolate and it was still distorted. so i closed chocolate again, opened chocolate setup and ESC'd out of chocolate setup and then launched chocolate one more time and chocolate was back to sounding correct again... i hope this makes more sense to you than it does to me. chocolate is in it's own folder, crispy is in it's own folder.

also, while testing i did notice something- that crispy doesn't seem to properly reproduce the L & R stereo music channels, the right side is significantly dominant & may have the left side mixed into it, and even more so the music channels seem reversed. this is not shown in the recording but while testing chocolate doom on E1M1 the music very clearly starts in the left speaker and then new music sounds begin in the right speaker doing to whole "look! stereo!" bit. however this is not the case when using crispy doom, all the music starts from the right speaker and remains very prominently there and is much more faintly heard from the left speaker.

[fabiangreffrath]

Hi @drivetheory ,

thank you very much for your detailed analysis! However, I am sorry to tell you that comparisons with Choco 3.0 do not really lead any further, since it has been released some 2.5 years ago and the SDL libraries bundled with it are several releases behind. For example, the default sound backend on Windows has been replaced in the meantime.

Would you mind carrying out the comparison with a daily Choco snapshot again? I am sure the differences will more or less vanish. Thanks!

[drivetheory]

no problem @fabiangreffrath , sorry for not doing that to begin with I'll download the latest daily build at http://latest.chocolate-doom.org/ and repeat the process.

[drivetheory]

so @fabiangreffrath , I've actually made 2 discoveries that you might find interesting/amusing/useful.

I downloaded both daily build for choco & crispy, you were correct, 99% identical problems exist in both.

at this point I downloaded versions 2.0.5 and newer of "SDL2.dll" & versions 2.0.1 and newer of "SDL2_mixer.dll" from www.libsdl.org and spent the past few hours this morning testing since it's a bit of a slow day for me.

discovery PT1

simply dropping in "SDL2_mixer.dll" v2.0.1 to either choco or crispy, (not touching the other DLL files) completely solves the problems i am experiencing.

the problems i am experiencing were created by changes made between "SDL2_mixer.dll" v2.0.1 and v2.0.2, most notably of which was "Updated for SDL 2.0.6 and newer" (https://www.libsdl.org/projects/SDL_mixer/), and lots of changes exist in SDL v2.0.6 (https://www.libsdl.org/tmp/SDL/WhatsNew.txt)

pairing SDL2_mixer v2.0.2 and SDL2 v.2.0.6 produces an entry point not found error regarding DSL_AudioStreamFlush not being located in SDL2.dll and crispy won't load, so much for being updated to work with v2.0.6 and newer.... however, pairing SDL2_mixer v2.0.2 and SDL2 v.2.0.7 (and newer) does allow doom to load and the distorted sounds are heard once again.

discovery PT2

using "SDL2_mixer.dll" v2.0.1 as i describe above actually shows very clearly the discrepancy between current code base of chocolate doom and crispy doom regarding the Left & Right stereo mixing.

in chocolate doom, in E1M1, the music starts playing in the left speaker, then the right speaker, and in crispy it's reversed.

included a screenshot of the audio recording. one of the nice features of the creative sound cards, they actually have a "what you hear" feature that turns the sound cards audio output into an input source, great for recording in situations like this.

sorry for all the edits, lots of typos...

[fabiangreffrath]

Thank you very much for the detailed analyses!

Re discovery 1: As I suspected thi s turns out to be an issue between SDL, SDL_Mixer and other parts of the audio stack including audio hardware drivers and the actual Windows audio API being used. Probably not much a Doom port deveoper can do about, especially since the current approach apparently works with some older releases of the same libraries.

Re discovery 2: Are you using the OPL audio backend? Because there is a bug in the OPL music code causing flipped stero channels that I unconditionaly fixed: https://github.com/fabiangreffrath/crispy-doom/blob/master/src/i_oplmusic.c#L1125

However, if it turns out that everyone got used to the Vanilla behaviour so much that the corrected stereo channels are considered as buggy, then I'll have to revert that fix.