Welcome to the ZDoom Forums!

Reported the issue to [b]libsndfile[/b] developers [url=https://github.com/erikd/libsndfile/issues/254]here[/url].

I doubt that the problem is with the library itself rather than with a compiler was used to buil it.
Like I said there is no issue with DLL I built with MSVC.

To report a bug some minimal sample is needed, we can't just say: build GZDoom with VS2015 in Release.

[quote="_mental_"]
The question is how do we proceed with libsndfile for minor release?[/quote]


If the library is the source of the problem it needs to be replaced. I also think the bug needs to be reported to its creator, this is a serious issue that could render it worthless.
For the time being I am putting back the old version into the binary distribution.

The main question is: Does this work for 64 bit due to the far stricter stack alignment requirements or just by random luck?

Both solutions sound good to me - so it's whatever you think is best.

After some thinking about this issue I came with conclusion that the best way to solve it is to rebuild all dependencies with MSVC.
I can do this myself if needed.
Alternatively, I can create Git repository with source code of all libraries we are using with configured VS projects/solutions and batch file to build them all.

Even after my fix I've got the same unaligned access in Debug Win32 build.
Apparently something is really wrong with libsndfile.

UPDATE: I built libsndfile from master branch using MSVC. Release DLL works fine with all GZDoom configurations. Most likely 1.0.28 was compiled with MinGW which is guilty of breaking alignment in stack.

The question is how do we proceed with libsndfile for minor release?

Such a requirement should never be made part of an ABI.

Fixed in [url=https://github.com/coelckers/gzdoom/commit/8a36bf5c09e6ca2ea6bab336869cf2e9a4ccb1e4]8a36bf5[/url]

Hard to say who is responsible for this fault, our code or libsndfile.
If SSE optimization was explicitly enabled during compilation of DLL, I guess we need to do proper buffer alignment.

In any case, it was quite easy to fix on our side.

I'm off for the entire day so I cannot test myself right now.
Can you retest this with the DLL from the 2.4 release? That's an older one.
This probably needs to be reported to the libsndfile developer if it can be confirmed to be a library related error.

Released 32-bit build crashes inside [b]libsndfile-1.dll[/b].

After some testing, I've come to the conclusion that the crash may be related to the sound played during quake effects, specifically their FLAC format, making the secret sound play by entering a secret sector or crossing a secret line also crashed the game for me, but it didn't when I added a custom DSSECRET via an external pk3, in WAV format.

Also, any value for the intensity, radius and tremor, even at minimum, the game will freeze no matter what.

I can get this too. It is just the 32 bit version though. The 64 bit version seems to work just fine.

Summary	0000640: Frozen status in GZDoom 3.0
Description	Activating a switch with a Radius_Quake action in GZDoom 3.0 32-bit version, the game will froze everytime. Tested on the 20 Monsters Challenge megawad, maps 25 and 38.
Steps To Reproduce	-Drag and load this provided wad in GZDoom.
-Select the Doom 2 Iwad.
-Press the switch in front of you.
-The game will froze because of the Radius_Quake action.
Additional Information	-Use the 32-bit stable version of GZDoom 3.0.0

https://mantis.zdoom.org/view.php?id=640
[code]Summary 0000640: Frozen status in GZDoom 3.0
Description Activating a switch with a Radius_Quake action in GZDoom 3.0 32-bit version, the game will froze everytime. Tested on the 20 Monsters Challenge megawad, maps 25 and 38.
Steps To Reproduce -Drag and load this provided wad in GZDoom.
-Select the Doom 2 Iwad.
-Press the switch in front of you.
-The game will froze because of the Radius_Quake action.
Additional Information -Use the 32-bit stable version of GZDoom 3.0.0[/code]
https://mantis.zdoom.org/file_download.php?file_id=224&type=bug