Created attachment 785405 [details] testcase User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20130803030205 Steps to reproduce: Go to the testcase and click the button Actual results: The two values for currentTime are the same Expected results: The two values should be about a second apart. This might be related to bug 587465: if you are performing a lot of calculation before checking currentTime it can be off.
This is intentional, we do not update the value of the currentTime attribute until you yield to the event loop.
Chrome does update the value, who is wrong?
(In reply to comment #2) > Chrome does update the value, who is wrong? Chrome, I believe. There is no way to implement this the way that Chrome does without locking with the audio thread. I believe I have raised this on public-audio but I cannot find a link to it right now... :(
Well, a number of client/server audio engines (PulseAudio, WASAPI, etc.) have the same problem, and simply interpolate linearly instead of locking to rendering/callback/audio hardware thread. We could do the same thing if we agree that we should doing that. It is very common to drive webgl or canvas animation from the audio clock (for easy audio/video synchronisation), and I believe people would expect to have Date.now(), performance.now() and AudioContext.currentTime to work in the same way.
(reverting the flag change).
Yeah I guess so, but I'd prefer to wait for people to ask for this first.
Would this be the proper place to ask for it? Right now I'm working around this bug using the performance counter, but I've been getting reports that it doesn't work for every browser/application, and having it act like it does in Chrome would fix it.
We are uncertain how best to work around the chrome/firefox difference in behavior here. Any help in https://github.com/kripken/emscripten/pull/1493 would be welcome.
The emscripten issue seems to have tons of information on it, but it's not obvious to me what you're trying to use currentTime for here. Can you please elaborate? I'm interested in the usecase to see if it's something that many apps would want to do.