[2.8.0] Sound cuts out when entering a SoundEnvironment

[MTrop]

Load up Adventures of Square. Walk outside Square's house in E1. Sound cuts out. Stays cut until you quit. Restarting the sound system does not work.

I'm hoping that this isn't a driver issue - the builds before this one used a different version of FMOD that worked. Anyone else experiencing this?

[edward850]

I have this feeling that the changes to fix reverb support in new versions of FMOD have broken the specific build Randi used for the official build. At a guess, the dsp buffers fall apart causing FMOD to fail. You have have two buffers playing at once, the second at a very latent time, or the reverb just fails entirely.

[randi]

I'll have a look at it later. I'm out of time now. But the logging version of FMOD (fmodexL.dll) works fine.

[randi]

Fixed. Now do I do a re-release right away or wait a few more days for 2.8.1?

FMOD 4.36 was chosen for the release because it's the last version with pre-XP support, but it's not one I actually tested on until now. When I decided to dig into what I was doing wrong to muck up sound on post-4.26 releases, it was at 4.38, so I just skipped over 4.36.

[Major Cooke]

It appears you fixed some surprisingly serious issues in this regard. I'd say 2.8.1 being released now wouldn't hurt.

[HavoX]

You could always do a 2.8.0.1, in case something else comes up...

[edward850]

2.8.0.½-Redux-FinalMix

[Blzut3]

I'd personally wait out tomorrow at least. Just do the release before Friday as I might be away next weekend.

By the way, what's with the double commits? Are we not merging maint into master anymore? The error in the 2.7 branch was an accidental master to maint merge. Graf's commit ordering looks like he committed to the wrong branch and then cherry picked, but yours look intentional so that's why I'm asking.

[randi]

By the way, what's with the double commits? Are we not merging maint into master anymore?

If I recall correctly, if we merge maint into master, running git describe --tags from master will pick up the tag from maint, since the path to it is shorter than the one earlier in master.

[Blzut3]

Yes, but that's solvable by just making an empty commit for the release tag. In my opinion that seems like a better option than double committing everything since that involves more work.

[Graf Zahl]

I normally did all release tags in GZDoom off the mainlines. That way they didn't become a problem. (i.e. when ready, branch off, change the version number, tag the new commit and delete the temp branch.)
Comparing cherry-picking with constant merging, what does it matter? You got the same number of commits anyway and the two lines remain clean. I'd avoid merging between them as much as possible. Please don't forget that for GZDoom at the moment there's two master and two maint branches so the less they affect each other the better.

And what makes you think that double-committing is more work? A cherry pick is just as easy as a merge.

[Blzut3]

Because I use the command line (on all platforms) so the following is much easier:

Code: Select all

git commit
git checkout master
git merge maint

[Graf Zahl]

See, and with a good GUI tool a cherry pick is no work at all. Just select the commit, click 'cherry pick' in the menu and press 'OK'.
Maybe that's why Randi and I don't think about such issues...

[Blzut3]

And because I use the command line tools I don't think about such issues as how branches cross each other.

[randi]

Actually, I use the command line too. The only guis I use are "git gui" and "gitk".