(Solved)Sound causes stutters in GZDoom

[Bigcmj]

Edit: See the last post for solution.

Looking for some advice,

When im playing GZDoom with any gameplay changing mod(Project Brutality, Brutal Doom, Russian Overkill), I get half a second stutters when picking up a new weapon or firing it for the first time. I've tried messing with the display settings but no luck, but I found when playing with "-nosound" command, the stutter disappears. I tried updating my audio drivers but it didn't work.
Any suggestions would be appreciated.

My specs are an I7-6700HQ
GTX 1060
8GB RAM

[Rachael]

What version of GZDoom are you using? It sounds like you have a bad copy of OpenAL.

[Bigcmj]

Sorry, I never included that did I, im using the the most up to date version 3.7.1.

[Chris]

Are you using a mechanical/spinning HD, or an SSD? Do you have any anti-virus running in the background? The symptom of stuttering when first playing a sound (but be fine with subsequent plays) would tend to indicate it's slow to read the file from the drive.

[Bigcmj]

Hey, just wanted to give an update.
I tried reinstalling OpenAL, but that didn't make any difference, however after moving GZDoom and the mods I was using over to my SSD, The stuttering is gone! I kind of feel silly, having not thought of that.

Thank you both for your help!

[Guest]

Move openal32.dll out of the folder that gzdoom is in, it fixed it for me, it seems to use the native windows version that works inside windows OS instead of one .dll in root of gzdoom. I wish I would have found this fix years ago.

[Graf Zahl]

Move openal32.dll out of the folder that gzdoom is in, it fixed it for me, it seems to use the native windows version that works inside windows OS instead of one .dll in root of gzdoom. I wish I would have found this fix years ago.

That is dangerous. If you move out that DLL you have no guarantees that the version you get is the proper one. GZDoom requires a recent OpenAL soft implementation, it will *not* work as intended with a "system " OpenAL which in most cases is the long abandoned version from Creative.

[SanyaWaffles]

It's frustrating to see people do this stuff as a solution. It might seem to solve problems in the short term, but it's going to cause more in the long term. DLL Hell is certainly an awful thing.

Also... OpenAL isn't native to Windows. It's a third party library. As Graf said, there's no guarantee you're going to get the proper version. GZDoom requires a very specific library to function... the fact GZDoom is still running at all is kind of a miracle all things considered.

Especially since Bigcmj said their problem was solved with an unrelated problem - it was a slow hard drive and not any OpenAL issue it seems.

[Graf Zahl]

the fact GZDoom is still running at all is kind of a miracle all things considered.

Not really. OpenAL has a stable API and uses an extension model to expose new features. So the code would generally work. But since GZDoom relies on the presence of some extensions, any implementation missing them would not produce a correct sound field.

[SanyaWaffles]

I guess that's good then, but still. Just deleting DLLs and hoping that works doesn't seem to be good advice.

[Graf Zahl]

No, quite the contrary. If any application comes bundled with a set of DLLs - that's the ones it was developed for and they should not be swapped out unless recommended by the author of the software itself.

Of course with OpenAL there's the added complication that this library originally advertised itself as a system extension that really had to be installed to work. Even the current OAL-Soft distribution is designed to work with this model.

[Chris]

Of course with OpenAL there's the added complication that this library originally advertised itself as a system extension that really had to be installed to work. Even the current OAL-Soft distribution is designed to work with this model.

It would be nice if there was a nicer way to do all this, but I don't know how to best do a third-party SDK distribution for Windows/MSVC (most of what I've seen is an installer drops headers/libs/dlls in c:\program files and the developer is responsible for doing whatever more for each project), I'm not familiar with making installers, so that doesn't help (and relatedly, it would be good to have separate packages for user system installer and a developer SDK).

[Graf Zahl]

Regarding Windows SDK packages, the biggest annoyance here is that CMake still can't be made to autodetect vcpkg - if it could do that, a lot of these problem would be gone.