Skip to content

audio: Regression in closely spaced sound effects #10067

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

Closed
n0samu opened this issue Mar 15, 2023 · 3 comments
Closed

audio: Regression in closely spaced sound effects #10067

n0samu opened this issue Mar 15, 2023 · 3 comments
Labels
A-audio Area: Audio A-web Area: Web & Extensions bug Something isn't working regression Something was working before, but is now broken

Comments

@n0samu
Copy link
Member

n0samu commented Mar 15, 2023

#9671 seems to have caused a regression with sound effects that play in quick succession. Now the sound effects are playing at the same time as each other instead of one at a time and in order. It seems to be particularly happening at the start of movies before a stable audio buffer size has been established, but I can't 100% confirm that. The intro in this version of Electricman 2 provides a good demonstration of this problem: electricman2_dx.zip (First mentioned by @Zinc-Exclamation)

Using Ruffle-Regressions, we can observe that the DX Interactive intro sounded fine in nightly 2023-03-11, but in nightly 2023-03-12 (the first build with the dynamic audio buffer), the intro sound effects don't play correctly. We can hear fewer of them because some are playing at the same time as each other rather than in sequence.

electricman2_audio_regression.mp4
@n0samu n0samu added bug Something isn't working A-web Area: Web & Extensions A-audio Area: Audio regression Something was working before, but is now broken labels Mar 15, 2023
@torokati44
Copy link
Member

Yes, this is most likely due to the buffer length being chucked way up early in the content, when lots of initialization is taking place. And any change in which set of sounds to play can also only happen at the granularity of the buffer fill interval, which is around 370 ms (as configured currently) in the worst case.

This aligns well with the audio at the end of your screen capture:
image

Some possible solutions for this are:

  • Remember when any sound was requested to start, and play them all delayed by the current buffer duration, not right at the start of the next buffer window.
    • This might not be the best, especially in fast paced stuff like the above intro.
  • Cut off the beginning of the sounds that just started playing, so at least the next buffer contains "exactly what it should", with no delay.
    • I don't think this is acceptable in most cases.
  • Tune the buffer size algorithm somewhat, like by adding a warmup period where the buffer size is not increased, even if it causes some stutter.
    • I think this what I'm going to try to do.

@n0samu
Copy link
Member Author

n0samu commented Mar 15, 2023

Tune the buffer size algorithm somewhat, like by adding a warmup period where the buffer size is not increased, even if it causes some stutter.

I think this what I'm going to try to do.

Sounds good, thank you!

@n0samu
Copy link
Member Author

n0samu commented Mar 17, 2023

Fixed by #10095 🎉

@n0samu n0samu closed this as completed Mar 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-audio Area: Audio A-web Area: Web & Extensions bug Something isn't working regression Something was working before, but is now broken
Projects
None yet
Development

No branches or pull requests

2 participants