Inaccurate timing of tones causes race conditions
The timing of tones drift away from the (theoretically) 60 Hz update loop, causing some notes to immediately stop due to race conditions, i.e. a new tone is triggered at the frame when the last tone is supposed to stop, but the stop actually happens *immediately after* the new tone has been registered.

Example: the following cartridge plays two successive tones, but once in every 10-20 restarts the second one is not heard (also, even when it is, the gap between the two tones can be audibly large).

```c
void update () {
  static int T = 0;   // Frame count
  if (T == 10) tone(440, 20, 20, TONE_PULSE1 | TONE_MODE1); // Spans frames 10-30
  if (T == 30) tone(550, 40, 20, TONE_PULSE1 | TONE_MODE1); // Spans frames 30-70
  T++;
}
```

This problem affects both Firefox and Chrome on my machine, and may be a hindrance to sequencing music as well as create glitches among sound effects.

For the Web runtime's APU, one viable solution is synchronizing on/off events to frame updates, instead of letting WebAudio automatically stop them. There surely may be better approaches, and I would be delighted to help with implementation or testing if needed.