Bugzilla

The reason why these tests are flaky right now seems to be because when there is a delay between setting the timer for the next tone, and calling the tonechange event handler, the _next_ time the tonechange handler is called will appear to happen too soon. An example:

0ms: Schedule next tone to fire in 170ms.
* some processing delay *
2ms: tonechange handler called, remembers time, expects next call in 170ms, at t=172ms
170ms: Next tone fires, right on time
170ms: tonechange handler called, and test is sad

The reason why these tests are flaky right now seems to be because when there is a delay between setting the timer for the next tone, and calling the tonechange event handler, the _next_ time the tonechange handler is called will appear to happen too soon. An example:

0ms: Schedule next tone to fire in 170ms.
... some processing delay
2ms: tonechange handler called, remembers time, expects next call in 170ms, at t=172ms
170ms: Next tone fires, right on time
170ms: tonechange handler called, and test is sad