r1037 (+ GZD r123) Loud buzzing noise

[Enjay]

There is a loud buzzing noise on some maps. I didn't notice it with the versions released before today (I forget which number I had actually compiled) and it did not happen with GZdoom r122 either.

It seems to only happen with add on maps so maybe it's something to do with ambient sounds or something.

Here's a video of my own Overlord WAD in r1037 to illustrate the point. Don't worry about the sky using the notexture thingy, it's supposed to be a GZdoom skybox.

http://www.rowand.myzen.co.uk/noisy.wmv

[Graf Zahl]

The problem is caused by the ambient sound things. I'm too tired to investigate further though.

Another thing I noticed while testing this: FSoundChan::Mover neither contains a read barrier nor is it processed in any way by the garbage collector. I got a crash with Operation Overlord with this when I was quitting.

[randi]

It shouldn't be needing any special garbage handling if everything is working right, though, since one of the things the actor's Destroy() is supposed to do is detach all the sounds from it.

[Graf Zahl]

It still crashed because it pointed to something invalid.

[Graf Zahl]

I was able to fix the immediate cause but I don't know what caused it to make this odd buzzing noise instead. It sounds as if the sound was restarted over and over again so I suspect some hidden problem in the sound code that accidentally got triggered by the error in the ambient sound thing.

Maybe Randy can say more so I'm leaving this report open. My change was as follows:

Line 1884 in s_advsound.cpp:

Code: Select all

			S_StartSound (&this->x, this, NULL, CHAN_BODY|CHAN_LOOP, ambient->sound,
				ambient->volume, ambient->attenuation);

The first parameter was NULL in the previous non-working revision.

[randi]

This does highlight one major failing of looping sound playback: The caller is responsible for checking that a looping sound is still playing and restarting it if it stops. This should be handled transparently by the sound code.

[Graf Zahl]

Ok, good to know. But since a design flaw isn't a bug...

[randi]

...a design flaw which has now been rectified.

Also, this:

It still crashed because it pointed to something invalid.

Was because the ambient sound called S_StartSound() without a valid point, and because S_RelinkSound() looked at points instead of actors. So it was two errors, working in tandem that caused it to crash. You fixed the one, so that stopped the crash and also properly flagged the actor as making a sound, which stopped it from trying to restart the sound every tic.

[Enjay]

Any sounds that were playing when you saved will still be playing when you load.

Thank you. That's a mainly cosmetic, but very, very welcome improvement.

[Graf Zahl]

Any sounds that were playing when you saved will still be playing when you load.

Thank you. That's a mainly cosmetic,

Actually not. Imagine a sound containing an important message but interrupted by saving and quitting. You'd have had no chance to hear the rest.

[Enjay]

Hence the "mainly".

[Slasher]

IMO, a sound that contains important information, that isn't also displayed as text or something, would be a bad design choice on the modder's part.

But otherwise yes, I agree and am pleased the annoying noise is gone.

[Graf Zahl]

IMO, a sound that contains important information, that isn't also displayed as text or something, would be a bad design choice on the modder's part.

People still do it.

[Slasher]

On the other hand, it could partially be called the player's fault as well. I mean come on, who saves and quits right in the middle of an important message?

[Gez]

IMO, a sound that contains important information, that isn't also displayed as text or something, would be a bad design choice on the modder's part.

Welcome to Strife. It does have a log feature, but it isn't always used.