Jukka said: I tested this now on Macbook Air from 2011 running Windows 7 in bootcamp with the latest Nightly, and I can reproduce the issue. The problem seems to be that audio playback times start drifting in Nightly. The longer you have been playing the game, the more delayed audio playback becomes. When the game first loads, audio effects play out ok e.g. in the lobby level, but for example when you enter a capture the flag level (talk to Janitor NPC and join a match) and start playing, audio effects play out already 5-10 seconds after they should occur. At the end of the level, audio effects got as far as one minute from their cued playback time. Firefox Aurora 28.0a2 (2013-12-16) and Stable 26.0 worked ok without a lag for two capture the flag games. Only Nightly 29.0a1 (2013-12-16) exhibited this problem. Luke, perhaps you played for a longer period on the first time so that the audio drifted so far that it was practically "audio does not play back", and on the second go, verified that audio is working by listening to the sounds effects in the lobby screen right after loading? Can you test again on a Windows computer if you can reproduce? I do not have the game sources, but took a glance at the .js files in the FF debugger. The file WebAudioDevice.js seems to implement that audio effect playback, and it only uses soundSource.start(0); directives to play back audio, so it should always play back immediately. If the drift was an internal game bug, I would assume it would reproduce on all browser versions, so this leads to suspect that the drift occurs inside Firefox and .start(0); might not immediately start the playback in Nightly. Since this is a timing/drift issue, it might be an important to try out on a low-power hardware to reproduce. My Macbook Air runs the game at perhaps 15-20fps, so testing on a computer that does not give smooth 60fps could be important.

It would be helpful if we can get a reduced testcase...

[Fri, 18 Oct 2013] [14:12:57] <karl> roc: the MSG looks like it produces a number of frames calculated from the system clock. What corrects for differences between this and the number of frames that cubeb wants? [Fri, 18 Oct 2013] [14:13:19] <roc> nothing

I believe this will be resolved when Bug 848954 is fixed. Since Paul owns Bug 848954, I'm assigning this bug to Paul to verify that this issue is fixed when the fix for Bug 848954 lands.

The large delays reported here and the regression range make me suspect that this might have been mostly caused by bug 966867, which would be fixed in tomorrow's nightly.

Jukka --- Per Karl's comment above (Comment 4) can you retest Monster Madness once bug 966867 hits Nightly? Thanks.

Hey, sorry for the delay, I was travelling at a work week last week. Tested this again today on OSX and Windows 7 with the latest Nightly, and there is no accumulating delays in audio anymore. Happy to mark this down as resolved!

Verified based on comment 6