Skip to content

Home

Jump to bottom
Jack Schaedler edited this page May 31, 2020 · 3 revisions

Here's a place to collect some findings on how karplus-stress-tester behaves in different browsers, on different devices. This will grow as the page is tested in more contexts.

Findings/impressions from 28/5/2020

  • On a MacbookAir (10.14.6).
  • Firefox Nightly 78.0a1 (2020-05-19) (64-bit).
  • Chrome Version 83.0.4103.61 (Official Build) (64-bit).

In general:

  • MessagePort is not a good option for continuously passing lots of data between threads. It makes perfect sense for passing large objects infrequently (eg. WASM code fetched from a server), but severely limits performance if it's used to frequently pass lots of (even small) values. Using MessagePort will introduce glitches far before you run out of DSP/rendering capacity.
    • For example: Select 600 strings, 100 strings per worklet, WebAssembly, and ensure that visualization is on.
    • Notice that the page is very glitchy when using MessagePort. Switching to SharedArrayBuffer makes the glitches go away.
  • Currently, Firefox holds up better under load, and is more resilient to glitches from "external" activity on the machine.
    • For example: Select 1000 strings, 100 strings per worklet, WebAssembly, and ensure that visualization is on. In Firefox, this setup does not glitch. In Chrome, this currently glitches, and when scrolling the page, the audio will glitch. Also, scrolling in an external text editor or launching other applications will lead to glitches in Chrome, but not in Firefox. See: https://hacks.mozilla.org/2020/05/high-performance-web-audio-with-audioworklet-in-firefox/ for more background on why this is so. Also, it's my understanding that these issues are being addressed by the Chrome team.
  • Just-in-time compiled JavaScript is really fast!
  • I'm surprised that I can get 1000 strings running when the DSP is written in plain JavaScript. WebAssembly seems to provide something like a 2x speedup over the JavaScript version
    • For example: Given the optimal settings of 100 strings per worklet, and the use of SharedArrayBuffer, I can get 1000 strings running in Firefox without glitches using JavaScript. Switching to WebAssembly allows me to simulate 2000 strings with only occasional glitches. If I switch back to JavaScript, I get completely garbled audio.
Clone this wiki locally