Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

leadin sound not played for looping sound shaders

Closed
IvanTheB opened this issue May 19, 2020 · 11 comments
Closed

leadin sound not played for looping sound shaders #291

IvanTheB opened this issue May 19, 2020 · 11 comments

Comments

@IvanTheB
Copy link

IvanTheB commented May 19, 2020

Given the following shader, the leadin sound is played in vanilla D3, but not in dhewm.

Steps to reproduce:

  1. Save the following in sound/bug.sndshd
loop_with_leadin {
	minDistance	2
	maxDistance	25
	volume		7
	looping

	leadin sound/weapons/chaingun/cg_windup_mix_01.wav
	sound/weapons/chaingun/cg_motor_loop_01.wav
}
  1. run game and type: testSound loop_with_leadin
@DanielGibson
Copy link
Member

DanielGibson commented May 21, 2020

The weird thing is, the leadin seems to work with (some?) shaders that come with the game, like testSound sputter_on_01 (from sound/lights.sndshd)?!
One difference is that even though it says sound/lights/power_on_lights/activate_loop_on_01.wav it's really an .ogg file (but the engine has fallback logic for that - if it can't find the .wav it replaces the file ending with .ogg and tries again)

@DanielGibson
Copy link
Member

DanielGibson commented May 22, 2020

More specifically, this seems to work if the main (non leadin-) sound is an .ogg

loop_with_leadin {
	minDistance	2
	maxDistance	25
	volume		7
	looping

	leadin		sound/weapons/chaingun/cg_windup_mix_01.wav
	//leadin	sound/lights/power_on_lights/activate_loop_on_01.wav // really an .ogg
	//sound/weapons/chaingun/cg_motor_loop_01.wav
	sound/lights/power_on_lights/loop_on_01.wav // really an .ogg
}

no matter which leadin I use, apparently it's only played if the main/loop sound is an ogg..
If I convert cg_motor_loop_01.wav to .ogg (and rename the .wav) it works.

I guess I'll have to do some proper debugging

@IvanTheB
Copy link
Author

IvanTheB commented May 22, 2020

Thanks! That's already a good investigation. I hope you can find the problem.
I'll also try to look into this more deeply, but I'm not familiar with the sound system code.

@revility
Copy link

revility commented May 23, 2020

If i'm reading this correctly, it is detecting one file format, but not back on the other like it should. I have had this problem with vanilla D3 years and years ago.

@DanielGibson DanielGibson transferred this issue from dhewm/dhewm3-sdk May 23, 2020
DanielGibson added a commit that referenced this issue May 23, 2020
If the main sound in a shader was a .wav
(soundShader->entries[0]->hardwareBuffer == true), only that sound was
played (and looped with AL_LOOPING), even if a leadin was configured.
If the main sound was an .ogg it worked.
Not it should always work.
@DanielGibson
Copy link
Member

DanielGibson commented May 23, 2020

(I've transferred this issue to the dhewm3 repository because it's a bug in the engine, not in the SDK-part of the code)

I'm pretty sure this issue already existed in original Doom3, at least when using OpenAL (dhewm3 only supports OpenAL for sound output).
It's here:
https://github.com/id-Software/DOOM-3/blob/master/neo/sound/snd_world.cpp#L1755

The problem is:

	if ( ( !looping && chan->leadinSample->hardwareBuffer ) || ( looping && chan->soundShader->entries[0]->hardwareBuffer ) ) {
		// handle uncompressed (non streaming) single shot and looping sounds
		if ( chan->triggered ) {
			alSourcei( chan->openalSource, AL_BUFFER, looping ? chan->soundShader->entries[0]->openalBuffer : chan->leadinSample->openalBuffer );
		}
	} else {
		// ...

looping && chan->soundShader->entries[0]->hardwareBuffer is true for looping sounds where the main sound is a .wav (not .ogg) (hardwareBuffer means it just uploads all the raw sound data from the .wav into the OpenAL buffer that is played).
alSourcei( chan->openalSource, AL_BUFFER, looping ? chan->soundShader->entries[0]->openalBuffer : chan->leadinSample->openalBuffer ) means that if looping is true, alSourcei() tells the source to use the chan->soundShader->entries[0]->openalBuffer buffer - that's the one of the main (looping) sound, not the leadin.
Also, a few lines above: alSourcei( chan->openalSource, AL_LOOPING, ( looping && chan->soundShader->entries[0]->hardwareBuffer ) ? AL_TRUE : AL_FALSE ); sets the source to AL_LOOPING if looping is true and the main sound is a .wav.
This means that just the main sound is used and looped by openal.
(the else-case of the code above is much more complicated and handles streaming from .ogg, but it also handles leadin sounds and switching from leadin to "main" sound correctly)

Anyway, I think I have a fix in the following branch: https://github.com/dhewm/dhewm3/tree/fix-looping-sound-leadin
Can someone test it? I only tested a bit with testSound in the console (and only on Linux), I think this should be tested a bit more thoroughly before it goes into master.

@IvanTheB
Copy link
Author

IvanTheB commented May 27, 2020

@DanielGibson Thanks a lot for this! I'll test it in the next days!

DanielGibson added a commit that referenced this issue May 28, 2020
If the main sound in a shader was a .wav
(soundShader->entries[0]->hardwareBuffer == true), only that sound was
played (and looped with AL_LOOPING), even if a leadin was configured.
If the main sound was an .ogg it worked.
Not it should always work.
@DanielGibson
Copy link
Member

DanielGibson commented May 29, 2020

I created a fresh (Win32) build with this fix (and some more) included, based on the openal-fixes branch): dhewm3-oal-fixes.zip
Please test! :)

@IvanTheB
Copy link
Author

IvanTheB commented May 30, 2020

Your fix seems to have solved the issue. Thanks!
I'll now play the game some more paying particular attention to sounds.
I'll report my findings here within a couple of days.

@IvanTheB
Copy link
Author

IvanTheB commented Jun 1, 2020

I played some more maps and I didn't find any issue with your fixes. :D
I think we can close this once they are merged!

@DanielGibson
Copy link
Member

DanielGibson commented Jun 1, 2020

Awesome, thanks for testing!

@DanielGibson
Copy link
Member

DanielGibson commented Jun 1, 2020

This fix in master, but I have another OpenAL related fix that needs testing, see #296

There you can also get Windows binaries for testing that include all the OpenAL fixes of the build linked above, the aforementioned timing fix and latest changes from master.
Thanks in advance for testing! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants