After numerous changes of volume/pitch, they became less responsive about scratch-audio HOT 8 OPEN

We have no expectation that behavior seen using tools other than Scratch will represent the behavior using Scratch. Can you experience this behavior using Scratch?

from scratch-audio.

Okay, I put the project playing for 2 hours in the vanilla Scratch to see how the behavior is noticable, and here's the result.

from scratch-audio.

I made a test for a quick reproduction of the behaviour: https://scratch.mit.edu/projects/481050174/
It became slower and slower until the page reloaded again.

However, when the audio assets removed and the same audio reuploaded again, it became more responsive again.

from scratch-audio.

Here's an even more minimal version of @Kouzeru's project. It no longer makes much noise, but it still calls "set pitch effect" as fast as it can. You can watch the "set effect calls per second" drop very quickly after startup. Stopping the project and starting it again does not restore initial performance, but reloading the page does.

sound effects per second.sb3.zip

from scratch-audio.

Here's GarboMuffin's approach upon tackling this problem by doing optimisation upon sound effect changes
TurboWarp/scratch-vm@bffe350

from scratch-audio.

When is this fixed? Is anyone allowed to contribute?

from scratch-audio.

Hello, from testing, this actually appears to be an issue with your code. Since loops without a screen update have zero delay at the end of the loop, it will take an indeterminate amount of time, anything you run in the loop will eat into that loop (so it takes longer to loop). It is jot regulated to take some specific amount of time because that would break frequently and often if it was.

The biggest problem is the if statement where you check the time. Since this would end up running each time you run the loop (for example 1,000s to 10,000s of times per second. Conditional statements (not maths) cause a higher amount of CPU time than other instructions. To not have this random delay, you should instead use the "repeat until" block, which only checks every reasonable amount of time. But that will be too fast (1/10,000 usually) so you should do something like this instead

when green flag clicked
    set [thisFrameNo v] to (0)
    forever
        change [thisFrameNo v] by (1)
        show // do something that updates the screen
    end
end

when green flag clicked
    start sound [mySound.ogg v]
    set [lastFrameNo v] to (0)
    set [changesPerSecond v] to (0)
    forever
        set [nextTick v] to (round (timer + 0.5))
        repeat until <not (timer) < (nextTick)> // greater than or equal to
            repeat until <not <lastFrameNo = thisFrameNo>>
                change pitch by (1 / 512)
                change [changesPerSecond v] by (1)
                wait (1 / 2000)
            end
        end
        say (changesPerSecond)
        set [changesPerSecond v] to (0)
    end
end

from scratch-audio.

Cwilisf already got the issue right. The purpose of the quick loop in the project is only to hasten the effect, so you don't need to wait for the performance drops to build up.

You see you got the 10000 loops per secs at the initial, then it drops lower. And resetting the project does not restore the performance.

This seems to have an insignificant effect for simple projects that don't use the sound blocks intensively. This however causes some problems for the complex project of mine, and the others.

from scratch-audio.