Crispy Doom 6.0 (Update: Mar 31, 2023)

[fabian]

20 hours ago, ckjb1969 said:

and if there is further tests you need done just ask.

 

The distorted sound issue only affects SFX, not music, right?

 

Could you please perform another test? Revert back to the original Crispy release setup, i.e. the Crispy SDL*.dll files and "use_libsamplerate 1" in the config file. Does it make a difference if you set "snd_samplerate" to e.g. 96000 (or 48000? or 192000?) in the config file?

[ckjb1969]

@fabian

 

The distortion only affects the SFX, music is yet another issue, i will explain in a moment. 

With the original Crispy SDL files changing the snd_samplerate has absolutely no effect. Likewise changing the computers sample rate never made a difference either..

 

I am finding a music discrepancy also now.. after mucking around in the crispy setup changing the music to anything will kill it. I.E. no music. initially after the cfg file is created with no messing with the crispy setup sound interface the cfg result is: "snd_dmxoption                 "-opl3" and "opl_io_port                   0x388" after actually sellecting the same settings that are in the cfg file and saving settings and running.... dead no music. something just breaks, as deleting the cfg file does not restore music. a fresh unzip of the crispy file fixes that problem unfortunately.

[ckjb1969]

@fabian

 

I have confirmed that swapping out the SDL.dll files with the Chocolate Doom ones ALSO fixes this problem, as i was able to change opl2,3 back and forth with no problem (cannot test the other midi options as i do not have the files) -those crispy sdl libraries are looking to be a menace imo

[chungy]

You forgot to change the version number in configure.ac :)

 

https://github.com/fabiangreffrath/crispy-doom/blob/crispy-doom-5.3/configure.ac

[fabian]

*sigh* This is probably the last time I have put out a Windows release like this. From now on a "release" will be a tag in the GIT repo (and an announcement) and people will be referred to downloading a recent development snapshot. I am really tired of wasting my (and probably anyone else's) time with doing my own Windows builds. :(

[NightFright]

Questions regarding Timidity support:
1) Does Timidity provided with Crispy Doom support soundfonts (SF2)? I think I read somewhere that the one from Chocolate Doom doesn't since it's and old version.

2) Does Timidity support zipfiles as indicated here (under "Syntax"/dir cmd)?

 

I am asking this because I am trying to find a way to bypass the annoying issue of not being able to adjust music volume when using "Native MIDI" synth.

[Danfun64]

9 hours ago, NightFright said:

1) Does Timidity provided with Crispy Doom support soundfonts (SF2)? I think I read somewhere that the one from Chocolate Doom doesn't since it's and old version.

3

No, it does not. You'll have to setup some GUS patches. I recommend 8MBGMPAT. You need to make a new directory and extract everything in the zip to it. Then you need to edit crispy-doom.cfg (or chocolate-doom.cfg if using Chocolate) and change the timidity_cfg_path to the file address (for me it's C:\Users\Danfu\Documents\doom\8mbgmpat\timidity.cfg , but it of course depends on where you put the patches)

[galileo31dos01]

@fabian I have a question regarding to music formats, does Crispy Doom support OGG (and others besides midi)?? The reason why I ask is because I got this supposedly "limit-removing" wad called Sacrament (sacrment.wad) which has all tracks in ogg format, and I wanted to see if it works in crispy, but I don't hear any music in the game at all. Then I downloaded the music pack for crispy and extracted everything in the same folder with the wad, and still can't hear music.

[Jon]

On 8/14/2018 at 9:32 AM, NightFright said:

I am asking this because I am trying to find a way to bypass the annoying issue of not being able to adjust music volume when using "Native MIDI" synth.

 

I thought this was fixed by {chocolate,crispy}-midiproc?

 

5 hours ago, galileo31dos01 said:

@fabian I have a question regarding to music formats, does Crispy Doom support OGG (and others besides midi)?? The reason why I ask is because I got this supposedly "limit-removing" wad called Sacrament (sacrment.wad) which has all tracks in ogg format, and I wanted to see if it works in crispy, but I don't hear any music in the game at all. Then I downloaded the music pack for crispy and extracted everything in the same folder with the wad, and still can't hear music.

 

It does, but not as lumps in WAD files (I believe). As with Chocolate, the system looks up a mapping of in-wad music lumps to out-of-WAD ogg files via a sha1 hash of the in-wad LUMP. e.g. this line

b2e05b4e8dff8d76f8f4c3a724e7dbd365390536 = doom1-music/d_inter.flac

tells the engine that, whenever it is about to play a music lump with the sha1 checksum of b2e05(etc), instead, play the file doom1-music/d_inter.flac (relative to the music pack CFG). Taken from the sample music pack CFGs here

 

So to achieve what you want, I think you'd need to extract the lumps and build a cfg file that mapped sha1sums of the lumps to local paths for them. The lumps in the WAD would also need to be named in such a way that the vanilla engine tried to play them.

 

 

[Novaseer]

For whatever reason, the pitch of each sound (apart from music) is far, far higher than it should be. It hurts my ears.

[fabian]

On 8/14/2018 at 10:32 AM, NightFright said:

1) Does Timidity provided with Crispy Doom support soundfonts (SF2)?

 

I'd rather recommend to install the supplementary Music Pack which contains the fluidsynth library and a SF2 soundfont as well as some batch files to help getting things started.

 

11 hours ago, Jon said:

It does, but not as lumps in WAD files (I believe)

 

@galileo31dos01 Fortunately, @Jon is wrong here. Crispy Doom supports music lumps in any file format that your SDL2_mixer library supports.

 

6 hours ago, Novaseer said:

For whatever reason, the pitch of each sound (apart from music) is far, far higher than it should be. It hurts my ears.

 

I'll probably have some news on this tomorrow.

Edited August 15, 2018 by fabian

[fabian]

On 8/13/2018 at 8:42 PM, chungy said:

You forgot to change the version number in configure.ac :)

 

I have just re-released 5.3 today, this time from the right commit and with the libraries un-stripped (maybe this makes a difference on Windows), thanks @chungy and @Zodomaniac.

[galileo31dos01]

1 hour ago, fabian said:

@galileo31dos01 Fortunately, @Jon is wrong here. Crispy Doom supports music lumps in any file format that your SDL2_mixer library supports.

 

Does that mean I should be doing what Jon said here?:

 

8 hours ago, Jon said:

So to achieve what you want, I think you'd need to extract the lumps and build a cfg file that mapped sha1sums of the lumps to local paths for them. The lumps in the WAD would also need to be named in such a way that the vanilla engine tried to play them.

 

and also select another configuration in the setup? I have OPL3 by default. For example in PRBoom+ has OPL selected and I still can hear the tracks in ogg. Sorry for so many questions, I'm not familiar with this stuff :/

[fabian]

2 hours ago, galileo31dos01 said:

Does that mean I should be doing what Jon said here?:

 

Well, no, it should work out-of-the-box.

Edit: ... and does so on Linux.

Edited August 15, 2018 by fabian

[galileo31dos01]

I'm on Windows 7 btw. So, I must be missing something to do, or the wad simply isn't compatible with Crispy (5.3)? It's really odd, the text file mentions "PRBoom+" as recommended only because of ogg music, nothing about specific compatibility with that port. I tried executing the bat files from the music pack, and there's still silence in the game, except for sound effects of course. 

 

The wad is here. 

 

EDIT: HOLY MOTHER OF, I made it work, forgive me once again Fabian :s

Edited August 15, 2018 by galileo31dos01

[fabian]

42 minutes ago, galileo31dos01 said:

IEDIT: HOLY MOTHER OF, I made it work, forgive me once again Fabian :s

 

No problem, glad you made it! ;)

[fabian]

Heads up, Windows users (especially those with sound issues)!

Please help me to finally track down the sound issues with Crispy Doom on Windows.

1. Please download today's daily build of Crispy Doom here: http://latest.chocolate-doom.org/
2. Replace crispy-doom.exe from the 5.3 release with the one from the daily build - but no other file (yet)!
3. Start a new game and type the SDLAUDIO cheat, a message will appear that reveals the SDL audio backend
4. Please report your Windows version, your SDL audio backend and your sound experience here.
5. Then, you are encouraged to repeat the test with other DLLs, e.g. the ones from the daily build or from the latest Choco release

Examples:

Windows 7, WASABI, sounds like crap with DLLs from the Crispy release

Windows XP 64-bit, directsound, sounds fine with DLLs from the Crispy release

 

Thank you very much everybody!

[HAK3180]

Windows 10 64-bit, Wasapi, fine.

 

I've never had problems, by the way.

 

[galileo31dos01]

- Windows 7 Home Premium, 64 bits.

- SDL Audio Driver messages: when OPL3 it sends "Wasapi", when digital music pack it sends "xaudio2".

- All work fine apparently, also never had issues myself with sound/music in any release. 

[ckjb1969]

Windows 10 Home 64-bit, Wasapi, bad sfx with crispy SDL files

after swapping out the SDL.dlls  to the new daily builds SFX is normal, no discrepancy.

(Daily build exe and daily build SDL.DLL'S replaced in build 5.3 directory = perfect working order)

 

(Side note:  With the above configuration I no longer have the MIDI or music issue when editing the music selection in Crispy Setup. I.E. i can make changes in crispy setup without loosing my midi music, although i do notice the volume drop after selecting any midi option. I assume it has something to do with like general midi vs opl3? while its not a bug and i can always turn up the music volume in the game, i felt i could mention it here. also note that this volume drop occurred in Chocolate doom.)

[bradharding]

Windows 10 Home Build 1803, WASAPI, getting the "cartoon" sounds. I believe I got a similar report from a user after the release of SDL 2.0.6. After a bit of research on https://discourse.libsdl.org/ I force Windows to use the DirectSound driver (putenv("SDL_AUDIODRIVER=DirectSound")). Although that user hasn't got back to me, nobody else has reported anything similar.

 

Edit: Switching to WASAPI in DR by not setting the SDL_AUDIODRIVER environment variable gives me the cartoon sounds.

Edited August 16, 2018 by bradharding

[MAJ]

I replace 5.3 exe with the one from the daily build, type in game SDLAUDIO and result: Windows 7 Ultimate SP1, WASAPI (with P) and nothing change - cartoon sounds.

7 hours ago, fabian said:

Then, you are encouraged to repeat the test with other DLLs, e.g. the ones from the daily build or from the latest Choco release

Which ones? And what about exe, should I keep daily build exe?

Edited August 17, 2018 by MAJ

[Julia Nechaevskaya]

Windows 10 LTSB 64-bit: 

- WASAPI (5.3 release, dev Crispy executable) 

- XAUDIO2 (5.3 release, dev Crispy executable and dev Choco DLLs).

 

Everything sounds fine with both variants. I've also was never having a cartoonish sounds.

 

Edit: same results on Windows 7 Enterprise, 64-bit.

Edited August 17, 2018 by Julia Nechaevskaya

[Jon]

Lol at Fabian giving very precise instructions and most people not following them

[fabian]

12 hours ago, bradharding said:

I force Windows to use the DirectSound driver (putenv("SDL_AUDIODRIVER=DirectSound")).

 

Thanks Brad, I guess I'll have to do the same then.

 

Understandingly, the MSYS2 maintainers weren't too fond of disabling or degrading the WASAPI backend in SDL2 and instead suggested the same: https://github.com/Alexpux/MINGW-packages/issues/4223#issuecomment-413765500

 

Edit: @bradharding I have one question, though: By calling SDL_setenv("SDL_AUDIODRIVER", "DirectSound", true) with the last parameter being "true" you override any previous value set for the "SDL_AUDIODRIVER" variable, effectively clearing out the chance to test with any other audio backend. Is this intentional?

Edited August 17, 2018 by fabian

[bradharding]

9 hours ago, fabian said:

I have one question, though: By calling SDL_setenv("SDL_AUDIODRIVER", "DirectSound", true) with the last parameter being "true" you override any previous value set for the "SDL_AUDIODRIVER" variable, effectively clearing out the chance to test with any other audio backend. Is this intentional?

Yes, it was intentional because I know DirectSound works. (I was only using the standard putenv() until yesterday.) But you're right, it may be worth setting it to false, and then I'll output to console if the variable has changed.

[fabian]

On 8/17/2018 at 7:14 AM, Julia Nechaevskaya said:

- XAUDIO2 (5.3 release, dev Crispy executable and dev Choco DLLs).

I don't even know what the XAUDIO2 backend is. The next devel snapshot will force the directsound backend. Could you please confirm that everything still works as expected with the dev DLLs? Else I will have to introduce a runtime library version check. 

[Danfun64]

Force the directsound backend? What about those of us who aren't having these sound issues and want to use different backends? Also, shouldn't such a change be implemented in upstream Chocolate Doom first instead of a Crispy specific change?

[fabian]

4 hours ago, Danfun64 said:

Force the directsound backend? What about those of us who aren't having these sound issues and want to use different backends?

 

Well, "force" here means that it is set as the new default. You are still free to choose your own audio backend by setting the SDL_AUDIODRIVER environment variable.

 

Quote

Also, shouldn't such a change be implemented in upstream Chocolate Doom first instead of a Crispy specific change?

 

In general, yes. But Choco is still unaffected, because it is (deliberately?) built and released with an outdated SDL library, which doesn't yet have the faulty WASAPI backend.

[Julia Nechaevskaya]

On 8/18/2018 at 1:47 PM, fabian said:

I don't even know what the XAUDIO2 backend is. The next devel snapshot will force the directsound backend. Could you please confirm that everything still works as expected with the dev DLLs? Else I will have to introduce a runtime library version check. 

 

Oh dang, I've missed your message. Checked just now dev Crispy build with dev Choco DLLs - everything is fine. But now DLLs seems to be same in both dev Crispy and Choco?