While the background sound track plays, the sound effects (gunshots, etc) in Monster Madness appear to be missing, but only on Windows (I checked that they are present on Linux). Contact me for user/pass if you don't already have 'em.

Oh, I forgot to mention: this problem apparently only happens on Nightly, so it's a recent regression.

(In reply to Luke Wagner [:luke] from comment #1) > Oh, I forgot to mention: this problem apparently only happens on Nightly, so > it's a recent regression. Luke -- Were you able to verify that it worked in the latest Aurora (27)? I'm just wondering if you have any kind of regression range. Added Karl, Roc, JW, Marc S to the bug (both Ehsan and Paul are on PTO) -- Can someone help Luke with narrowing the regression range and help confirm that this is a Web Audio regression bug?

Oops, it looks like we're in the middle of changing trains. I can confirm that FF26 does not have the regression and FF27 does.

This sounds similar to bug 929969. I don't have an account for playverse, so I can't test this bug. A reduced testcase would be most appreciated, I've had no help in bug 929969 getting one either.

(Responded to Chris with name/pass in via email.)

So testing on Win8.1 with today's Nightly I don't see anything that looks like a problem. On my Windows 7 machine I get a crash loading the game on a worker thread with the following stack: TbsJava.dll!099e228b() Unknown [Frames below may be incorrect and/or missing, no symbols loaded for TbsJava.dll] ECTbsWrapper.dll!052f11ef() Unknown ECTbsWrapper.dll!052f1016() Unknown JitPI.dll!052c478b() Unknown JitPI.dll!052c4f14() Unknown JitPI.dll!052c90c6() Unknown SMP.dll!099d3bc5() Unknown 0c65d7f8() Unknown SMP.dll!099d2db7() Unknown 0c65d824() Unknown SMP.dll!099d9531() Unknown SMP.dll!099d9435() Unknown SMP.dll!099d102f() Unknown JitPI.dll!052c7b84() Unknown JitPI.dll!052c785e() Unknown JitPI.dll!052d63cc() Unknown JitPI.dll!052c745f() Unknown mozjs.dll!loadiJIT_Funcs(...) Line 440 C mozjs.dll!iJIT_IsProfilingActive(...) Line 316 C mozjs.dll!IsVTuneProfilingActive() Line 15 C++ mozjs.dll!GenerateCode(`anonymous-namespace'::ModuleCompiler & m, `anonymous-namespace'::ModuleCompiler::Func & func, js::jit::MIRGenerator & mir, js::jit::LIRGraph & lir) Line 4958 C++ mozjs.dll!GenerateCodeForFinishedJob(`anonymous-namespace'::ModuleCompiler & m, ParallelGroupState & group, js::AsmJSParallelTask * * outTask) Line 5132 C++ mozjs.dll!CheckFunctionsParallelImpl(`anonymous-namespace'::ModuleCompiler & m, ParallelGroupState & group) Line 5169 C++ mozjs.dll!CheckFunctionsParallel(`anonymous-namespace'::ModuleCompiler & m) Line 5276 C++ mozjs.dll!CheckModule(js::ExclusiveContext * cx, js::frontend::Parser<js::frontend::FullParseHandler> & parser, js::frontend::ParseNode * stmtList, js::ScopedJSDeletePtr<js::AsmJSModule> * moduleOut, js::ScopedJSFreePtr<char> * compilationTimeReport) Line 6405 C++ mozjs.dll!js::CompileAsmJS(js::ExclusiveContext * cx, js::frontend::Parser<js::frontend::FullParseHandler> & parser, js::frontend::ParseNode * stmtList, bool * validated) Line 6494 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::asmJS(js::frontend::ParseNode * list) Line 2534 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::maybeParseDirective(js::frontend::ParseNode * list, js::frontend::ParseNode * pn, bool * cont) Line 2610 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::statements() Line 2654 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::functionBody(js::frontend::FunctionSyntaxKind kind, js::frontend::Parser<js::frontend::FullParseHandler>::FunctionBodyType type) Line 1067 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::functionArgsAndBodyGeneric(js::frontend::ParseNode * pn, JS::Handle<JSFunction *> fun, js::frontend::FunctionType type, js::frontend::FunctionSyntaxKind kind, js::frontend::Directives * newDirectives) Line 2321 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::functionArgsAndBody(js::frontend::ParseNode * pn, JS::Handle<JSFunction *> fun, js::frontend::FunctionType type, js::frontend::FunctionSyntaxKind kind, js::GeneratorKind generatorKind, js::frontend::Directives inheritedDirectives, js::frontend::Directives * newDirectives) Line 2173 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::functionDef(JS::Handle<js::PropertyName *> funName, const js::frontend::TokenStream::Position & start, js::frontend::FunctionType type, js::frontend::FunctionSyntaxKind kind, js::GeneratorKind generatorKind) Line 1995 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::functionExpr() Line 2476 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::primaryExpr(js::frontend::TokenKind tt) Line 6874 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::memberExpr(js::frontend::TokenKind tt, bool allowCallSyntax) Line 6287 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::unaryExpr() Line 5535 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::assignExpr() Line 5373 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::expr() Line 5066 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::parenExpr(bool * genexp) Line 6896 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::primaryExpr(js::frontend::TokenKind tt) Line 6802 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::memberExpr(js::frontend::TokenKind tt, bool allowCallSyntax) Line 6287 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::unaryExpr() Line 5535 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::assignExpr() Line 5373 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::variables(js::frontend::ParseNodeKind kind, bool * psimple, js::StaticBlockObject * blockObj, js::frontend::VarContext varContext) Line 3578 C++ mozjs.dll!js::frontend::Parser<js::frontend::FullParseHandler>::statement(bool canHaveDirectives) Line 4975 C++ mozjs.dll!js::frontend::CompileScript(js::ExclusiveContext * cx, js::LifoAlloc * alloc, JS::Handle<JSObject *> scopeChain, JS::Handle<JSScript *> evalCaller, const JS::CompileOptions & options, const wchar_t * chars, unsigned int length, JSString * source_, unsigned int staticLevel, js::SourceCompressionTask * extraSct) Line 320 C++ mozjs.dll!js::WorkerThread::handleParseWorkload(js::WorkerThreadState & state) Line 747 C++ mozjs.dll!js::WorkerThread::threadLoop() Line 922 C++ nss3.dll!_PR_NativeRunThread(void * arg) Line 419 C nss3.dll!pr_root(void * arg) Line 90 C msvcr100.dll!_callthreadstartex() Line 314 C msvcr100.dll!_threadstartex(void * ptd) Line 292 C kernel32.dll!@BaseThreadInitThunk@12() Unknown ntdll.dll!___RtlUserThreadStart@8() Unknown ntdll.dll!__RtlUserThreadStart@8() Unknown I don't have symbols for all those DLLs, is there something on my system (like VTune?) that's interefering with my build? So I can't test this on Win7 until that's resolved. Anyway, assuming the "audio not playing" bug Windows 7 only, and assuming they're using either MP3 or MP4/AAC audio, I'd guess that this is caused by bug 933830. If they're using MP3, it would be good to know if they still get this error when we playback using DirectShow. You/they/someone can test this by testing a Nightly build from before 2013-10-25, which used DirectShow for MP3 playback, whereas after that date we switched (back) to using Windows Media Foundation (we originally used WMF, but tried to switch to DirectShow in Fx26, but had a regression after and switched back to DirectShow on Windows). If the bug goes away in Nightly builds from before 2013-10-25, then the fix is to switch Firefox to DirectShow (Edwin Flores is working on the regression now). If they're using M4A audio then the bug is probably bug 933830, which is going to take a few months to get fixed given the current work load of the media team.

(In reply to Chris Pearce (:cpearce) from comment #6) > If they're using MP3, it would be good to know if they still get this error > when we playback using DirectShow. You/they/someone can test this by testing > a Nightly build from before 2013-10-25, which used DirectShow for MP3 > playback, whereas after that date we switched (back) to using Windows Media > Foundation (we originally used WMF, but tried to switch to DirectShow in > Fx26, but had a regression after and switched back to DirectShow on Windows). I made a typo here: we switched back to WMF, not DirectShow!

Ah, sounds like the VTune integration is busted when VTune is installed. We should get that fixed. A build with --disable-profiling (or a machine w/o VTune) should avoid the crash. So I bisected down to the offending Nightly: Last good is 2013-10-17: http://hg.mozilla.org/mozilla-central/rev/423b9c30c73d First bad is 2013-10-18: http://hg.mozilla.org/mozilla-central/rev/4e7d1e2c93a6 Any obvious breakage in this range? I'll ask the devs whether what sound format they're using.

Bug 907817, bug 918861, bug 927322, and bug 925381 are in that range, perhaps more likely one of the first two.

Range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=423b9c30c73d&tochange=4e7d1e2c93a6 I agree with Karl; the only changesets that could conceivably cause that in this range are Paul's.

The game devs say they are using Ogg Vorbis.

Any Monster Madness bugs that affect functionality are P1s. Luke -- Are you still seeing problems in Nightly?

Looks like it work now!

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.

(In reply to Jukka Jylänki from comment #14) (Unmarking confidential since the game is not released.) This drift sounds like a different bug. The original bug I saw was zero sounds effects, starting immediately in the lobby.

Opened 960106 for the drift issue, closing this one.