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

Godot 4 - Audio clips have their beginning cut off #66452

Open
Tracked by #76797
FractalDiane opened this issue Sep 26, 2022 · 19 comments
Open
Tracked by #76797

Godot 4 - Audio clips have their beginning cut off #66452

FractalDiane opened this issue Sep 26, 2022 · 19 comments

Comments

@FractalDiane
Copy link

FractalDiane commented Sep 26, 2022

Godot version

v4.0.beta1.official [20d6672]

System information

Windows 10, Vulkan, NVidia RTX 2070 Super

Issue description

In Godot 4, some audio clips sound incorrect in engine for me; it sounds like the start is being cut off. I've tried both .ogg and .wav files and it happens with both, I've tried tweaking the import settings on the sound to no effect, and I've tried an identical setup in Godot 3.4.2 and the issue does not occur.

Here's a video comparing the original sound file, the sound in Godot 4, and the sound in Godot 3. You can hear that in Godot 4 the sound file sounds less "sharp" at the beginning as it does in the original file and Godot 3. Both these projects were created with no changes made to any settings.

Desktop.2022.09.26.-.08.31.04.02.mp4

Steps to reproduce

  1. Create a new project in Godot 4
  2. Import a short sound like the one I used (It's most noticeable on very short 8-bit style sounds)
  3. Play through the preview or through an AudioStreamPlayer and compare with the original sound file

Minimal reproduction project

Godot 4.0 beta project:
Soundtest.zip

Godot 3.4.2 project:
Soundtest3.zip

@FractalDiane
Copy link
Author

Update: This is still happening in Beta 8.

@Calinou
Copy link
Member

Calinou commented Dec 18, 2022

This may be an intentional measure to prevent audible clicks when looping sounds rapidly (which was a common issue throughout Godot 3.x).

cc @ellenhp

@FractalDiane
Copy link
Author

@Calinou Do you know where this was implemented? I looked through recent-ish audio commits and @ellenhp's recent commits but couldn't find anything that looked related.

@ellenhp
Copy link
Contributor

ellenhp commented Jan 20, 2023

The fade in/out logic is all in servers/audio_server.cpp. The main mixing loop is pretty well documented but I will say that due to the way atomics are used, the structure of it is pretty fragile so large changes could have serious and unexpected stability implications. You can try tweaking some of the parameters in there though, and possibly in the associated header file. Constants should be totally fine to tweak. Please do update this bug if you find some values that work better for a wide variety of audio files. The ones that are going to be the most likely to have issues are low frequency tones, especially if they don't start at a zero-crossing.

edit: Also test play(x) for random x to make sure that the shorter fade-ins don't cause pops when they happen at random points in the waveform.

@FractalDiane
Copy link
Author

@ellenhp I've been playing around with some constants in audio_server.cpp, but I'm not sure I've been looking at the correct ones (This is starting on line 357):

if (mixed_frames != buffer_size) {
			// We know we have at least the size of our lookahead buffer for fade-out purposes.

			float fadeout_base = 0.94;
			float fadeout_coefficient = 1;
			static_assert(LOOKAHEAD_BUFFER_SIZE == 64, "Update fadeout_base and comment here if you change LOOKAHEAD_BUFFER_SIZE.");
			// 0.94 ^ 64 = 0.01906. There might still be a pop but it'll be way better than if we didn't do this.
			for (unsigned int idx = mixed_frames; idx < buffer_size; idx++) {
				fadeout_coefficient *= fadeout_base;
				buf[idx] *= fadeout_coefficient;
			}
			AudioStreamPlaybackListNode::PlaybackState new_state;
			new_state = AudioStreamPlaybackListNode::AWAITING_DELETION;
			playback->state.store(new_state);
		} else {
			// Move the last little bit of what we just mixed into our lookahead buffer.
			for (int i = 0; i < LOOKAHEAD_BUFFER_SIZE; i++) {
				playback->lookahead[i] = buf[buffer_size + i];
			}
		}

I tried messing with fadeout_base and fadeout_constant, and setting them high enough does bring back an extreme pop at the end of the sample, but it doesn't get rid of the beginning of the clip being cut off. Commenting out the entirety of the multiplying the buffer by the constants also seems to do nothing.

Is there a different section of this code that handles the start of the audio clip? I tried changing LOOKAHEAD_BUFFER_SIZE but that didn't do anything audible.

@ellenhp
Copy link
Contributor

ellenhp commented Jan 21, 2023

Oh weird, it looks like I never implemented proper fade-in, so the volume ramp code is what is preventing pops on fade-in. Does changing buffer size to something shorter like 128 or 64 make a difference? https://github.com/godotengine/godot/blob/master/servers/audio_server.cpp#LL1346C2-L1346C2

This is not a good workaround because it will increase CPU requirements, maybe dramatically. But it will work for diagnosing the issue.

@FractalDiane
Copy link
Author

@ellenhp It looks like reducing the buffer size does indeed fix the beginning being cut off. I tried a few different values and 160 seemed to be around the highest I could go with it sounding correct. The next highest I tried was 192 and there I noticed it being cut off.

@ellenhp
Copy link
Contributor

ellenhp commented Jan 21, 2023

Could you test #71780?

@FractalDiane
Copy link
Author

FractalDiane commented Jan 21, 2023

Looks like #71780 fixed the issue on my end!

@akien-mga akien-mga modified the milestones: 4.0, 4.1 Feb 22, 2023
@YouveBeen
Copy link

I think i'm having this issue.
Strangely it was working fine until it didn't. I now have a cut-off after each few shots on my guns. Sounds like OP's problem.

@YouveBeen
Copy link

Ok i've found my issue.
My game is made to work at 10 physics ticks per second to save on computing power because i can have a lot of enemies and physic stuff happening at the same time and everything works fine so far like this (The project is almost done) except now, sound.
If i bring back the physics ticks to 60 the cut-off goes away. Starts getting better around 30 ticks.

Not sure how and why the audio is tied to the physics update ticks. My audio calls are made in _process function so it's not on my end.

@tivtag
Copy link

tivtag commented May 1, 2023

Having this issue with Godot 4.0.2, where short audio files (mp3, wav) won't play at runtime with AudioStreamPlayer. This might be related to the beginning being cut off?

@YouveBeen
Copy link

Having this issue with Godot 4.0.2, where short audio files (mp3, wav) won't play at runtime with AudioStreamPlayer. This might be related to the beginning being cut off?

Does it work with longer audio files?

@tivtag
Copy link

tivtag commented May 1, 2023

Having this issue with Godot 4.0.2, where short audio files (mp3, wav) won't play at runtime with AudioStreamPlayer. This might be related to the beginning being cut off?

Does it work with longer audio files?

Good idea! :) I have tried it out and, no a longer audio file doesn't work either.

I've just tried to exchange the short audio file with a longer audio file, which works fine in different AudioStreamPlayer in another Node, and it doesn't play either. That's very strange, since I can't find any difference between the two AudioStreamPlayer instances!

@p3tina
Copy link

p3tina commented Nov 6, 2023

I'm still experiencing this issue in 4.1.3 stable. This is a video comparing a WAV sound effect played outside of Godot with how it sounds played in-engine. The start of the sound in-engine is noticeably quieter, making it less 'punchy'.

2023-11-06.20-34-52.mp4

@Calinou
Copy link
Member

Calinou commented Nov 6, 2023

If anyone is interested in fixing this, I suggest reading this comment first: #71780 (comment)

@YuriSizov YuriSizov removed this from the 4.2 milestone Nov 15, 2023
@YuriSizov YuriSizov added this to the 4.x milestone Nov 15, 2023
@Lompikzozh
Copy link

@thearst3rd
Copy link

Hello :) I just tested the above pull request (#87064) and it resolves the issue on my project. Here's a before and after comparison, which sounds correct to me: kdreese/gmtk-2022#72 (comment)
It's worth trying out that branch for anyone else experiencing the issue, since it fixes it for me and I'd love to see it get merged :) Thanks!

@ellenhp
Copy link
Contributor

ellenhp commented Apr 25, 2024

Glad to hear it worked! I don't have bandwidth to contribute right now but if someone wants to pick up those changes and get them merged I would love that. This is one of those bugs that I wrote a long time ago and feel really bad about, and I'd like to see it get fixed. :)

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