Sound effects play back differently between GZDoom versions

[Nevander]

I have noticed that the end result of firing a rapid fire weapon as far as the overall blended sound effect goes, it sounds like there is a cutoff or repeat of some kind happening between some versions of GZDoom, namely the ones I use (2.2.0 and 3.2.5). What I mean is, if you fire a rapid firing gun set to CHAN_AUTO, it should not be distinguishable that there is any kind of firing pattern in the sound effect from constant firing. This is the intended result to me when using a weapon such as this when on the auto channel.

To make things more clear, if you were to fire the Chaingun and Plasma Rifle in my mod constantly without letting go, you will notice that it sounds one way (the intended way) in version 2.2.0 of GZDoom and then do the same in the latest version, it will sound different as if there is some kind of pattern or limiting going on behind the scenes that changes the intended outcome of the sound when constantly fired.

Anyone know what's causing the difference and if there's a way to get it to sound like it does in 2.2.0 but in 3.2.5 onwards?

[Chris]

Neither OpenAL or the OpenAL backend should be limiting the number of instances of a particular sound (there's a limit to the total number of sounds, but FMOD had that too; and even if you do reach that limit, the OpenAL backend will prioritize which ones stay appropriately). Though there may have been a change in the higher-level sound code since 2.2.0 that causes this. In S_StartSound, for instance, I see:

Code: Select all

    int seen = 0;
    if (actor != NULL && channel == CHAN_AUTO)
    {
        // Select a channel that isn't already playing something.
        // Try channel 0 first, then travel from channel 7 down.
        ...
    }

    // If this actor is already playing something on the selected channel, stop it.
    if (type != SOURCE_None && ((actor == NULL && channel != CHAN_AUTO) || (actor != NULL && S_IsChannelUsed(actor, channel, &seen))))
    {
        for (chan = Channels; chan != NULL; chan = chan->NextChan)
        {
            if (chan->SourceType == type && chan->EntChannel == channel)
            {
                bool foundit;

                switch (type)
                {
                    case SOURCE_Actor:              foundit = (chan->Actor == actor);
                    break;
                    case SOURCE_Sector:             foundit = (chan->Sector == sec);
                    break;
                    case SOURCE_Polyobj:    foundit = (chan->Poly == poly);         break;
                    case SOURCE_Unattached: foundit = (chan->Point[0] == pt->X && chan->Point[2] == pt->Z && chan->Point[1] == pt->Y);              break;
                    default:                                foundit = false;        
                    break;
                }
                if (foundit)
                {
                    S_StopChannel(chan);
                    break;
                }
            }
        }
    }

Which looks like it prevents an actor from playing multiple sounds on the same channel. Other comments for S_CheckSoundLimit also suggest that if an actor plays a sound that it's already playing, the sound will be restarted. I'm not as familiar with this part of the sound code though, so someone else may need to chime in with what this all does and any relevant changes since 2.2.

[_mental_]

GZDoom 2.2.0 released with FMOD and OpenAL backends. So any sound or music issue should be tested in the same version but with different backends.
Moreover, there are newer versions than 2.2.0 that were built with both. Please test with 2.4.0 first, not with 3.2.5 against something old.

[Graf Zahl]

This also warrants the standard line: Please post a minimal runnable example. It's not fun to test such issues with a large mod.

[Nevander]

This also warrants the standard line: Please post a minimal runnable example. It's not fun to test such issues with a large mod.

Are you serious? My mod is like 23 MB when zipped. The issue is easily demonstrated within the mod as-is. I'm not going to take out only the Chaingun and it's code just for this.

[Graf Zahl]

Yes, we are serious. This is all about the entire rest of the content that may have an influence on how a bug manifests itself.
The more stuff gets loaded the harder it is to pinpoint the cause of a problem, especially when it's just about something being "different" and not something unambiguously wrong like a crash.

[_mental_]

If I got the bug report right it sounds differently to me since 2.3.0 regardless of sound backend. It certainly has nothing to do with switch to OpenAL.

EDIT: Actually it can reproduced with regular plasma rifle, with D64RTR the difference is little bit more noticeable.

[Nevander]

If I got the bug report right it sounds differently to me since 2.3.0 regardless of sound backend. It certainly has nothing to do with switch to OpenAL.

Basically, yes. I wasn't sure if it was OpenAL, I only said that because I only use FMOD in 2.2.0 and am forced to use OpenAL in 3.2.5, these are the two versions I use for development and testing. To me, this is a bug because it sounds different than I intended in 3.2.5. Does it mean it's really a bug? No, but I'd still want to know what's going on and why it's different, and furthermore if there's a way to make it sound exactly the same across both.

[_mental_]

Topic is titled 'Sound effects different with OpenAL'. I pointed out that this is wrong. I didn't say that it's not a bug.

[Nevander]

Topic is titled 'Sound effects different with OpenAL'. I pointed out that this is wrong. I didn't say that it's not a bug.

Gotcha. Edited the thread title so it's more right, I hope.

[Rachael]

This also warrants the standard line: Please post a minimal runnable example. It's not fun to test such issues with a large mod.

Are you serious? My mod is like 23 MB when zipped. The issue is easily demonstrated within the mod as-is. I'm not going to take out only the Chaingun and it's code just for this.

Do you want the bug fixed or not?

If not, feel free to not follow simple requests.

[Nevander]

Feel free to not care because you're too lazy to investigate yourself when you know engine stuff and the rest of us cavemen don't.

[wildweasel]

Feel free to not care because you're too lazy to investigate yourself when you know engine stuff and the rest of us cavemen don't.

It is not about laziness. It is about rooting out the actual cause. When it's JUST THE ONE THING and it can be PROVEN that the problem is with the way that ONE THING is being handled by the engine, then it's worth submitting to the devs. When there's 23 megabytes' worth of other things that could just as easily be the root cause of your problems, then it's not worth wasting the time. Because odds are, someone will be in the process of isolating the problem down to just the one thing, when suddenly, the problem ceases, and they haven't touched anything anywhere NEAR what the obvious cause was. So then the problem is, what WAS the root cause? And that's something that you, who knows your mod better than we do, should be doing - not the devs who already have a plate full of other bugs and things that need attention.

[Nash]

Feel free to not care because you're too lazy to investigate yourself when you know engine stuff and the rest of us cavemen don't.

The developers don't owe you anything. The engine is made out of their own free time and free will. You, on the other hand, owe them if you want something in your mod fixed.

If you're a paying customer then perhaps you may be a little more entitled (but even if you are a paying customer, the support team will ask you to follow certain procedures to help isolate a problem. Help THEM help you. Not the other way around... it's how everything in real life works )

[Graf Zahl]

If you're a paying customer then perhaps you may be a little more entitled (but even if you are a paying customer, the support team will ask you to follow certain procedures to help isolate a problem. Help THEM help you. Not the other way around... it's how everything in real life works )

Precisely that. Even customer support has only limited resources and they will certainly give priority to those issues where the information makes a quick resolution more likely.

And if it even goes down to doing a little investigation yourself when the problem started to occur.
Between version 2.2.0 and now lie roughly 17 months, I think the very least I expect from a reporter is trying to check THEMSELVES which one was the first to show the problem.

So what we got here is a report that "between 2.2.0 and 3.2.5 a problem started to occur". I beg your pardon? Did it start in 2.3, 2.4, 3.0, 3.1 or 3.2? That'd be the first thing I'd check if something doesn't work. Not even that did happen, one of the devs had to do it!