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

AudioStreamPlayer causes unpredictable behaviour in idle process #27590

Closed
Keetz opened this issue Apr 2, 2019 · 1 comment
Closed

AudioStreamPlayer causes unpredictable behaviour in idle process #27590

Keetz opened this issue Apr 2, 2019 · 1 comment
Assignees
Milestone

Comments

@Keetz
Copy link
Contributor

@Keetz Keetz commented Apr 2, 2019

Godot version:

Godot 3.1-stable

OS/device including version:

Issue description:

So, this is a weird one!
First I thought it was the timer node (#27437).
Then @Tugsav managed to find a possible fix to this issue, but @reduz isn't sure it actually makes sense (#27458).
Now I managed to create a reproduction project, but it isn't pretty, but it shows that there is an error!

I am pretty sure that the AudioStreamPlayer is the problem, and it causes the idle process across the game to behave very weird. It stops other things running in the idle process such as Particles and Animations. In some cases I also experienced particles and animations being sped up.

Steps to reproduce:
Run the project I included and keep your eyes on two things!

  1. See how the four animations and the particle system stops one at a time.
  2. Check the log output and notice a few things.
    2.1 ERROR: partitioner: bad comparison function; sorting will be broken At: ./core/sort_array.h:189.
    2.2 The outputs should come every 0.1 seconds, but it will start to speed up significant and print way faster.

There are a few things to do in the project that will result in different behaviours.

  • The script "Main.gd" does "audio.play()" and "audio.stop()" right after eachother in a while loop with some other code, if one of these lines or both are commented out, this whole error doesn't occur.

  • The node with the "Main.gd" script attached (Node) can be placed a few different places in the scene tree that will cause different behaviours. If it is placed as the top node, just below "Main" the while loop runs forever, but eventually all the animations and the particles will stop, and the idle process runs a lot faster (see log output being printed way faster than it should)
    Selection_056

  • If Node is placed as the last node in the tree the animations and the particles will continue working but the while loop will at some point straight up stop because the timer doesn't get the timeout signal correct and therefore hang forever.
    Selection_058

  • If Node is placed after the "ExtraScenes" node the behaviour is a mix of the two above. First the animations and the particles will stop, and when they all are stopped the while loop will stop as a result of the timer failing.
    Selection_057

So, to the solution provided by @Tugsav
Our thought about this is that the AudioStreamPlayer runs in the idle process and somehow is able to mess it up! To further prove that this is happening, go ahead and set one or more of the animation players in the scene to process mode physics and play the game again.
This will result in the animation players working as intended and never stop.

So the PR I linked to in the beginning makes the change to the AudioStreamPlayer, and that PR fixes this problem! But it might not be the correct solution as @reduz isn't completely convinced about the PR.

The solution is to make the AudioStreamPlayer run in physics process instead, just like the AudioStreamPlayer2D and AudioStreamPlayer3D does.

I really hope that this time around, the issue is way more clear, and that the reproduction project is enough to both prove that there is an issue and to help find a fix as this is quite a bad bug!

Minimal reproduction project:

test.tar.gz

@reduz

This comment has been minimized.

Copy link
Member

@reduz reduz commented Apr 27, 2019

This was caused by #25974, which was reverted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.