godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
88.98k stars 20.18k forks source link

Audio does not stop when pausing the project from the editor #68880

Open CookieBadger opened 1 year ago

CookieBadger commented 1 year ago

Godot version

4.0 beta5

System information

Windows10, AMD Ryzen 9 3900XT, RTX3070, Vulkan

Issue description

When audio is being played from an AudioStreamPlayer and the game is started, upon pausing the game from the Editor (see image), the audio keeps playing. This is especially problematic when the audio timing is critical for a game (i.e. Rythm games). The same happens when playing the audio from an Audio Playback Track of an animation player, even though the animation itself pauses and resumes properly, any audio just goes on.

image

Steps to reproduce

Minimal reproduction project

AudioStreamOnPause.zip

Calinou commented 1 year ago

@ExquisiterEmil Please upload a minimal reproduction project to make this easier to troubleshoot.

Does this occur in 3.5.1?

TokisanGames commented 1 year ago

Pausing audio streams works fine in beta5 when the scene tree is paused with: get_tree().paused = true

And the AudioStreamPlayer process_mode is set to PROCESS_MODE_PAUSABLE. Look at the help in Node: ProcessMode enum. Change it in the inspector under Node, or in code:

    var music_player := AudioStreamPlayer.new()
    music_player.process_mode = Node.PROCESS_MODE_PAUSABLE

Yes the editor pause button does not stop the music player in game with the above process_mode. That's a bug. However, I never use that button. Build pausing into your game with the code above and use that.

CookieBadger commented 1 year ago

@Calinou sure, minimal repro project added, I just thought that this is very very simple. Yes it occurs in 3.5.1.

Yes the editor pause button does not stop the music player in game with the above process_mode. That's a bug. However, I never use that button. Build pausing into your game with the code above and use that.

@tinmanjuggernaut if you don't use a feature, that does not mean that it being broken is unproblematic. I know that get_tree().paused works perfectly fine, however, the pause button is very helpful for debugging purposes. As I said, for games with time-critical audio, it is important, that this does not happen, so the game resumes properly. Also, the advantage of the Editor pause button is that it is supposed to stop all execution, not just the process loop of things that are pausable. And if the audio keeps playing, apart from breaking coherence, it is also annoying that I have to keep listening to the game's music, while doing profiling / looking at remote node properties, etc.

TokisanGames commented 1 year ago

I acknowledged that it is a bug.

pafuent commented 3 weeks ago

Probably this wont add too much value because I didn't find out a solution, but at least I could shed some light into this issue. Currently, when you pause the execution of your game, Godot only "pause" the main loop, so all the threads created are continuing with their execution. This applies to threads created with Thread and to all other threads created by Godot engine itself. If you are curious about where that "pause" happens check here On one of the previous comments was mentioned that AudioStreamPlayer pauses when get_tree().paused is being used. That is because AudioStreamPlayer is processing that message here. But, as I mentioned earlier, that message is not sent to AudioStreamPlayer because the Main loop execution was paused and no node is being notified. As this comment states, Godot engine doesn't keep track of threads, so there is not an easy way to pause those threads when the Main loop is paused when you press the ⏸️ button. Take all this with a grain of salt, because I barely understand the internals of Godot. Maybe a core maintainer would be able to say if there is a way to pause all the threads or at least clarify is this behavior is a design decision.

pafuent commented 3 weeks ago

BTW I tested this on 4.3 stable and the behavior is the same described at the top of this issue.