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

WAV: Fix one frame overflow at the end #96768

Merged
merged 1 commit into from
Sep 12, 2024
Merged

Conversation

DeeJayLSP
Copy link
Contributor

@DeeJayLSP DeeJayLSP commented Sep 9, 2024

This fixes AudioStreamWAV decoding one additional frame after the last


Problem

Let's assume a PCM data with exactly 3000 frames as an example. This means the range should be 0-2999.

When you mix in AudioStreamPlaybackWAV, it considers you have to decode p_frames frames into p_buffer. There is a calculation right before the decoder is called (limit, aux and target) that is supposed to prevent the decoder (do_resample()) to get an index beyond the PCM data range and repeat the while loop in respect to the audio loop mode.

Assuming the audio has no loop points and goes from the very first frame to the last, here's the problem: when playing forward, the last frame (end_limit in the mix function) is assumed to be the length of the audio data (3000), not the last index (2999). Because of that, target ends up being calculated considering that additional frame, out of the range, and ends up making do_resample() get one more frame than it should.

The reason no errors happen when playing PCM audio data is because of the DATA_PAD (which reads a 0 value frame at that position, leading to a barely audible pop), and doesn't crash with QOA data because the resampling workaround doesn't allow the offset to be above the last frame index.

Solution

Do what should be done: subtract 1 from the length whenever you point to the last frame.

Even if the while loop forces the audio to stop when the offset is beyond the last frame, it doesn't prevent that one extra end frame request from being passed to the decoder function.

If merged, any audio imported with any enabled Loop Mode and Loop End set to -1 will need to be reimported to remove the extra frame from the count. Not sure if this count as compatibility breaking, but existing projects should not be affected.

Considerations

I found this by experimenting with #83483 (makes AudioStreamWAV use PlaybackResampled, removing the need for workarounds and data pad) with a QOA audio with 4160 frames (the number becomes the decode buffer size when instantiating playback) and it would crash for not being able to get index 4160.

@DeeJayLSP DeeJayLSP requested a review from a team as a code owner September 9, 2024 19:26
@DeeJayLSP DeeJayLSP changed the title ResourceImporterWAV: Subtract 1 from frame count when setting loops WAV: Subtract 1 from length when setting end limits Sep 9, 2024
@akien-mga akien-mga added bug topic:audio topic:import cherrypick:4.3 Considered for cherry-picking into a future 4.3.x release labels Sep 10, 2024
@akien-mga akien-mga added this to the 4.4 milestone Sep 10, 2024
@akien-mga akien-mga requested a review from a team September 10, 2024 07:30
@DeeJayLSP
Copy link
Contributor Author

DeeJayLSP commented Sep 12, 2024

Force-push because I messed up the wrap on the importer.

And reworded the commit/PR to make it clear this is a fix.

@DeeJayLSP DeeJayLSP changed the title WAV: Subtract 1 from length when setting end limits WAV: Fix one frame overflow at the end Sep 12, 2024
@akien-mga akien-mga merged commit b998cb1 into godotengine:master Sep 12, 2024
20 checks passed
@akien-mga
Copy link
Member

Thanks!

@akien-mga
Copy link
Member

Cherry-picked for 4.3.1.

@akien-mga akien-mga removed the cherrypick:4.3 Considered for cherry-picking into a future 4.3.x release label Sep 16, 2024
Tekisasu-JohnK added a commit to TekisasuEngine/tekisasu that referenced this pull request Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants