Ok, I fixed it now, for real :) It's attached.
It seems that the web audio API has changed slightly since we wrote that code.
The difference is that I was calling it without specifying the "end" parameter, you were explicitly setting it to 120 (correctly), but this caused the sound to stop immediately due to another audio bug.
On a side note, you probably want to use the audio time for this, rather than a timer object which is ultimately based on the app's time. When there is a slow down for performance reasons (which is common when you load a scene with new assets and new textures for example), your wade app's time effectively slows down. An audio file that is playing on a different thread, in most cases, does not slow down.
You have 3 options really:
1. Assume that your users have a system that support WebAudio (i.e. no Internext Explorer, though Edge is fine). In this case you can do this extremely accurately using the web audio timer. When the sound start you do something like:
wade.app.soundStartTime = wade.getWebAudioContext().currentTime;
And later on, when you need to know how long ago the sound started playing:
var t = wade.getWebAudioContext().currentTime - wade.app.soundStartTime;
This is the most accurate method because it measures time in the same coordinate system as the sounds that are playing.
2. If you need to support internet explorer, you can assume (or hope) that the audio playback never stutters or slows down, in which case the audio timer is in sync with the system time.
wade.app.soundStartTime = Date.now() / 1000;
....
var t = Date.now() / 1000 - wade.app.soundStartTime;
3. Do both - if wade.isWebAudioSupported() use the first method, else use the second method.
On another side node, the game looks very good :)