Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
It has always been an issue that if you try to continously play
tone
each frame, you will get gaps due to frame timing issues. This has made doing live-playback or creating very fancy sounds difficult.The previous workaround has been to extend each
tone
so that the next one will override it, but this has several drawbacks when working with pitch-bends.What is done here is make the APU aware of WASM-4 ticks. This enables us to keep playing the active
tone
past its expiration as long as the next tick hasn't rolled in yet, thus avoiding gaps in playback.Demo
Here is a video demonstration of the fix: demo
This also shows that it only affects continously calling
tone
with sustain and doesn't affect intentional skipping or envelopes (which is correct.)Has been tested on both web and native, on Windows and Linux.
Example
Here's the cart I used to test this and the Zig code for it: cart.wasm
I also tested some code doing continous frequency sweeps and the difference is night and day, even when doing workarounds with the old version.