[Bug] Tone.js out of sync and glitching

[ghost]

Updated 8 July, 2022 for spelling

Describe the bug

When I have Tone.js play a song, the music comes out off beat a few times, and can glitch, flicker out, and/or buzz when playing certain notes (mainly when playing a3 concurrently with a4).

To Reproduce

Click here (opens StackBlitz) to open the editor. You may need to play the song a few times to see the full result.

Please note that the Vue setup is not the setup for my project; I chose the Vue template to build the basic setup, then added the necessary files.

Expected behavior

I expected the music to come out more consistently, without the unexpected noise and timing issues.

What I've tried N/A. It is with the Tone.js internals/ WA API (:white_check_mark: confirmed :arrow_down:).

Additional context Due to Tone.js's verbosity, I decided to create a more streamlined and composable API (see src/composer.js, which is already open in the editor); this API was inspired by RxJS. The API also logs the time at each advancement (see src/composer.js:53).

Specs:

• Laptop: Dell Insperion
• OS: Windows 10
• Browser: Firefox

[ghost]

Ok, I just tested the StackBlitz demo on my phone (Samsung with Android v12, relatively new) with three different browsers: Firefox for Android, Google Chrome, and Samsung Internet (which are all Chromium-based). On all three browsers, Tone.js was starting to get static-y; all three demos stayed on beat for the first round, but I can make the assumption that Tone.js will get off beat after a few rounds of pressing the 'Play' button. This testing allows me to conclude that this is either with the Tone.js API, or with the Web Audio API on Chromium-based browsers.

P.S. I did not try Microsoft Edge as it is Chromium-based as well.

[ghost]

I just checked the package.json (line 107), and I can pinpoint the issue to Tone.js, the standardized-audio-context package, or the Web Audio API. With this info, I have an idea on how to optimize our work in solving this issue.

• The Tone.js team can test the library itself for the bug.
• While the team checks the library, I will (try to) open an issue on the standardized-audio-context's repo.
• If the Tone.js team and/or the dependency conclude that the bug is with the browsers, then we will need to get the rest of the Tone.js community involved (possibly by pinning this issue) to get in contact with the browsers.
• This issue will be open until the bug is fixed either in Tone.js, or standardized-audio-context.

[ghost]

We have a new bug. Tried to use the native context, but it gave me an error. I accidentally reported it the issue I created about the standardized-audio-context dependency.

[chrisguttandin]

I rewrote the test case to make it a bit easier to follow (at least for me).

https://stackblitz.com/edit/js-wpswxb

I can reproduce the problem on an Android phone, too. It's happening on Chrome and Firefox (which is not Chromium based by the way). I had the feeling that lowering the volume helps a little. Therefore I added a Gain to make this testable. But it didn't solve the problem completely.

But I think lowering the volume makes sense. Since all the parallel oscillators easily make up a signal beyond the [-1, 1] range. And what the OS (Android in this case) does with a signal above the defined range is not specified.

To further test this I added another test case with a brickwall limiter. In combination with a very aggressive volume reduction it seems to solve the problem.

https://codesandbox.io/s/bold-waterfall-rteqir

I had to use CodeSandBox since StackBlitz gets confused when loading an AudioWorklet.

But even with these modifications I get occasional glitches. I'm not sure if there is something we can do to solve this. To really find out what causes this one would have to rewrite the test case without Tone.js and without standardized-audio-context. But I'm not sure if it's worth the effort.

[ghost]

I think I'm going to have to go a different way anyway. Thank you. I'll go ahead and close this issue.