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

Web audio samples : AudioStreamPlayer's finished() signal doesn't emit when sound is done playing. #93904

Closed
DinoMC opened this issue Jul 3, 2024 · 1 comment · Fixed by #94044

Comments

@DinoMC
Copy link

DinoMC commented Jul 3, 2024

Tested versions

System information

Godot v4.2.2.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 (NVIDIA; 32.0.15.5585) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 Threads)

Issue description

When running the project as a single threaded web export, AudioStreamPlayer's finished() signal doesn't fire, even after the sound is done playing.

This is still the case on very recent versions (latest build from workflows as of one hour ago) and I haven't found any existing issue mentioning this.

This seems bad as it breaks several popular AudioManager classes I have seen peoples use, which mean a lot of projects would end up with no sound (or crash) just from upgrading to 4.3.

(Edit : To be more accurate, the issue seems to be caused by the new AudioStreamPlayer playback_type property being set to "Sample", rather than the export template. If the AudtioStreamPlayers are manually set to Sample and the project is ran using the multithreaded web template, the issue will still occur)

Steps to reproduce

  • Create an AudioStreamPlayer node (either in editor on in script, both are affected).
  • Bind the finished() signal to a function, add a way to check if it ran.
  • Play a sound on that AudioStreamPlayer
  • Function won't run if you ran the project using the single threaded web export template (but will with multithreaded web, windows, etc... templates)

Minimal reproduction project (MRP)

AudioStreamPlayer finished bug MRP.zip

A simplified version of an AudioManager class I usually use. It creates a pool of AudioStreamPlayers (3 for this demo), remove one from the pool when a sound needs to be played, then add it back to the pool when the finished() signal emits.

Main scene plays a sound every second using this manager. If you run the project on most templates, the sound will repeat infinitely. If you run in with the single threaded web template, it'll play 3 sounds and then stops, as the Players never get added back to the pool.
(You can also just check the console and see that the debug print in the finished() callback never runs)

There is a second scene I used to test if the issue only occurred in some conditions, but the issue occurred in ALL cases (tried removing argument, creating the players in the scene rather than in gdscript, connecting the signal in editor rather than in gdscript, ...)

@DinoMC DinoMC changed the title NoThreads Web export : AudioStreamPlayer's finished() signal never emits NoThreads Web export : AudioStreamPlayer's finished() signal doesn't emit when sound is done playing. Jul 3, 2024
@AThousandShips AThousandShips added this to the 4.3 milestone Jul 3, 2024
@Calinou
Copy link
Member

Calinou commented Jul 3, 2024

cc @adamscott

@adamscott adamscott self-assigned this Jul 7, 2024
@adamscott adamscott changed the title NoThreads Web export : AudioStreamPlayer's finished() signal doesn't emit when sound is done playing. Web audio samples : AudioStreamPlayer's finished() signal doesn't emit when sound is done playing. Jul 7, 2024
@adamscott adamscott changed the title Web audio samples : AudioStreamPlayer's finished() signal doesn't emit when sound is done playing. Web audio samples : AudioStreamPlayer's finished() signal doesn't emit when sound is done playing. Jul 7, 2024
@akien-mga akien-mga moved this from Unassessed to Very Bad in 4.x Release Blockers Jul 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Very Bad
Development

Successfully merging a pull request may close this issue.

4 participants