Sound cutting

[Chris]

Some sounds are being cut at some point, and some don't even play correctly. Using the latest GZDoom (3.2.5) with Brutal Doom from dec 31.

Almost sounds like the different sound channels are preempting each other, with sounds that should overlap cutting each other off.

I've been having odd sound issues too. Made my own video for this, but on my end [not sure this is the global issue you might also be having but] the sounds likes to cut off or fade really quickly if the sound is supposed to be emitting on your LEFT side. Notice how when I turn right while firing the sound very quickly fades, but if I turn left while firing it doesn't. Seems to occur for sounds not directly emitted by the player, like projectiles that have their own sounds, enemy sounds, etc. :V

Can't say I notice anything wrong in these videos. At least, left panned sounds seem the same as right panned sounds. What is your audio setup like? I'd first double-check the sound device configuration in the control panel. Are you using headphones or speakers?

What we could do is add a linked repo if OpenAL uses Git, and then simply add it as a dependency for CMake and drop it into the release folder when it builds.

I'd just be careful with that. MSVC support is kind of tricky for OpenAL Soft since Microsoft doesn't seem to think C has updated since the early 90s, and though it should technically work correctly (and I'll gladly accept any patches/fixes related to improving MSVC support), I can't vouch for the quality of the build compared to using MinGW or Clang. In particular I know the handling of atomic variables is really nasty on MSVC, since I can't use C11's atomics or even certain tricks that C99 would allow.

Chris makes Windows binaries for releases of OpenAL Soft. These DLLs (built with MinGW I think) are used in our releases and devbuilds.
I'm more curious why versions are so different.

IIRC, Graf started using a version of OpenAL Soft he built himself because the binaries provided were causing link-time errors relating to SAFESEH. MinGW, of course, doesn't support Structured Exception Handling, and GZDoom is built with SAFESEH on (it's the default, I believe), so it was resulting in an error when linking a non-SAFESEH lib. You should be able to simply replace the DLL afterward, though.

[Korell]

I'm in agreement with Rachael here in that it doesn't appear to be something new. My tests showed the Brutal Doom v20 and v21 Beta Jan 02 both show some sounds cutting out when the weapon is switched out, but this happens in 3.2.5, 3.2.4 and 3.2.1 and even if I use the older OpenAL32.dll from 3.3pre-273. I imagine if I dug out an older GZDoom version that it would still show the same cutting out of the Mancubus Flame Cannon, Unmaker and BFG sounds if another weapon is switched to whilst the weapon sound is still playing.

I've not yet been able to replicate this with Doom 2 without mods. I've also tested it with Doom 64 Retribution, Brutal Doom 64 and Meta Doom 4.1, and I couldn't detect any sounds being cut. Lastly, I tested with Project Brutality v2.0 and the only weapon that I heard getting its sounds cut on switching out to a different weapon was the UAC41 Carbine. So at the moment it seems to me to be more related to the mods rather than GZDoom itself, maybe something to do with the sounds they are using or how they are coded to play them. I cannot say whether this is a GZDoom bug or bugs with the affected mods.

Out of interest, is the snd_channels maximum value of 256 set to that for a reason or could it be increased further? Would it help with this sound cutting if it could be set to a higher value?

[Chris]

Out of interest, is the snd_channels maximum value of 256 set to that for a reason or could it be increased further?

Older versions of OpenAL had a limit of 256 sound "sources" (the term "channels" gets confusing here since ZDoom also refers to channels as a kind of group, like "UI sounds" being a sound channel). Since OpenAL Soft 1.18, it allows requesting more than 256 sound sources, though realistically, if you're playing 256 sounds simultaneously there tends to be something that can be cut without noticing, like an ambient sound halfway across the map (ZDoom does this, if there's a lack of voices it'll cut the farthest least important sound if it's trying to play a closer or more important one).

Would it help with this sound cutting if it could be set to a higher value?

Unlikely. Though if you want, you can run 'stat sound' in the console which will show how many sounds it's trying to play, so you can see if it's at the limit.

[Lord Misfit]

An update on my situation: discovered that appearantly one of my external speakers crapped out this morning without my realizing it until then. I heard some crackling and scratchiness in them a few days ago and thought to get a new pair, but they won't be here until late this week. That's PROBABLY my issue explained, but I won't be able to confirm that until I get the new speakers though. x.x

I was also led to think my issue had more credence since a few people had said they detected a sound balance issue when they listened to my videos, but I have a feeling now, that they might have been thinking of something else. x.x;

[De-M-oN]

hmm apparently I dont have this issue in my game. I also play Project Brutality. My game seems to be fine though..

I use a Asus Xonar HDAV 1.3 soundcard with a Beyerdynamic DT770 Pro Headphone (it is stereo).

My game is set to 128 sound channels, but honestly: Does the game play so much sounds simultaneously? I remember at Zandronum 2 that more than a maximum of 8 simultanaous sounds didnt play entirely anymore, meaning the 8 channel limit is still present. I noticed it very often while playing All Out War 2 where many, many sounds are playing, especially with some more players and it was very frustrating to die by a suicide bomber, because he didnt play the screaming sound, because of all sound channels overloaded. And that were no way more than 256 sounds or 128. Especially if you watch out how often and how quick the problem kicks in. Is that else for gzdoom(3)?

But however, the sound system of gzdoom 3 seems really good.
I've set my xonar soundcard to 8 channel (which activates virtual surround on a stereo headphone) and the game has HRTF enabled.
Apparently I got with this quite impressive binaural sound. So for me the sound system works very good.

[Chris]

I've set my xonar soundcard to 8 channel (which activates virtual surround on a stereo headphone) and the game has HRTF enabled.

FWIW, GZDoom's (OpenAL's) HRTF option is only valid with stereo playback. By enabling the 8-channel virtual surround mode, you're making the driver pretend it's a 7.1 device where it applies its own HRTF to give virtual "surround sound" speakers (the in-game HRTF option is effectively ignored with non-stereo output). True HRTF is far more capable as it allows sounds to come from all over, including up and down and not just the 7.1 horizontal-only speaker positions, but requires stereo output for the filters to work.

[De-M-oN]

Awesome
Then I even have it in my youtube videos

I also noticed an echo of my footsteps in a big closed room.

I really have to praise the sound system of this game! Thats just impressive.
But I still like to ask about the sound channels. In AOW2 how said I noticed in Zandronum 2 that about 8 simultaneous sounds are enough that the system is overloaded and stops to play further ones (so if I'm in a mech and someone wanted to suicidebomb me I often couldnt notice him, because the entire screaming of the suicide bomber wasnt played anymore at all.

If I look here:
https://zdoom.org/wiki/A_PlaySound#Sound_slots

This should be still the case, isnt it?

What is the snd_channels setting for then? Does it make any sense to set it to 128, 256 or any high number if the engine can play only max 8 simultaneously? Or isnt it max 8 anymore?

PS: What means "FWIW"?

[Rachael]

FWIW = For What It's Worth

[Graf Zahl]

IIRC, Graf started using a version of OpenAL Soft he built himself because the binaries provided were causing link-time errors relating to SAFESEH. MinGW, of course, doesn't support Structured Exception Handling, and GZDoom is built with SAFESEH on (it's the default, I believe), so it was resulting in an error when linking a non-SAFESEH lib. You should be able to simply replace the DLL afterward, though.

Actually, no. You got a few things mixed up a bit. These were two different issues.

The one is that the import library does not work due to SAFESEH. In fact, your import library is not a genuine import library as it contains function stubs for each entry in the code segment. This is the reason why it causes problems with modern compilers on default settings. I never used that .lib file at any time because it would have forced me to change compile settings. In old versions I used a self-generated .lib but later switched to dynamic loading because the default OpenAL on Windows does not appear to play nice and overrode a local file on my system resulting in sound problems. Dynamically loading from an absolute path managed to work around this.

The self-compiled library was just because at that time the latest official download was a year old, it got replaced the moment a more recent official version appeared.