You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Audio playback is slowed down by anything happening in the UI thread. This is very often the case with the SheetMusic visualizer's logic (#101), but can also happen for any number of reasons ; resources are fluctuating in nature.
Thus, perhaps it would be better to isolate audio playback in its own thread, so that its setTimeouts are never delayed by UI thread events.
The text was updated successfully, but these errors were encountered:
I tried isolating setTimeout to its own worker in a branch, but it seems to have no effect. It also creates a hard-to-reproduce bug where sometimes playback becomes super-fast and impossible to stop. So this might not be the solution after all...but then, where do these delays come from ? They weren't there before visualizers were implemented.
The "super-fast playback" bug is probably solved with #127 (which forces clearTimeout() on every new call of playNextSet()), but still, use of a worker doesn't seem to result in any performance improvements.
Audio playback is slowed down by anything happening in the UI thread. This is very often the case with the SheetMusic visualizer's logic (#101), but can also happen for any number of reasons ; resources are fluctuating in nature.
Thus, perhaps it would be better to isolate audio playback in its own thread, so that its setTimeouts are never delayed by UI thread events.
The text was updated successfully, but these errors were encountered: