User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.6 (KHTML, like Gecko) Chrome/6.0.490.1 Safari/534.6
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b3) Gecko/20100805 Firefox/4.0b3
This example checks the audio.currentTime value 60 times per second. It then draws a *green* square when the currentTime value is bigger than in the previous frame. Draws a *blue* square when it's the same as in the previous frame. Draws a *red* square when is smaller than in the previous frame.
Steps to Reproduce:
1. Create an <audio> element
3. Listen to currentTime values
Because audio.currentTime doesn't report values with enough precission it's all full of blue squares (audio.currentTime reporting the same value in many frames).
audio.currentTime should report a different value (incremental) every frame, and the visualisations should be mainly green squares.
Created attachment 466116 [details]
Created attachment 466117 [details]
Created attachment 466118 [details]
Created attachment 466119 [details]
Created attachment 466121 [details]
Interesting testcase. We snap changes to the currentTime to video frame boundaries, originally so you got one timeupdate event per frame and so that the currentTime was likely to still have the same value for that frame. But because there's no such thing as an audio frame, Firefox arbitrarily defines an audio "frame" duration as 40ms, so we update our currentTime 25 times per second when playing back audio-only files. If you change your demo to update at 25 Hz rather than 60, we're basically all green.
How much of a problem is this? We can reduce the audio "frame" duration easily to improve the precision. How much precision do you need? A better fix otherwise probably wouldn't make Firefox 4.
The spec has also changed since our first implementation, and timeupdate events no longer need to be fired once per frame, so once we reduce our timeupdate frequency, we don't really need to snap the currentTime to frame durations.
A workaround I've been using is to get the currentTime on the first frame and then use new Date().getTime() on top of that, but if the audio happen to delay/pause/stop for some reason, then everything gets out of sync and we can't have much control on that. I guess it would be ideal to have, at least, 16ms precision.
(I don't know what's the precision in Chrome/Opera, but, as you can see, it's all green at 16ms)
A related problem that I have come across is that when I do a seek to a certain time, e.g. video.currentTime = 20, I never end up exactly on that time and instead on something like video.currentTime = 19.999000549316406. This results also in the little indicator on the controls displaying "19", which - for a user and Web developer - just seems wrong, since they seeked to 20 and not 19.
Neither Opera nor Chrome do this kind of seeking - they all end up returning the seeked time as 20.
That sounds like two different bugs to this one. Can you please file two new bugs?
The first bug is that the controls are rounding down rather than to nearest, by the sounds of it.
The second bug is that I think we only seek as accurately as a frame, so if you seek to a point that's inside a frame duration (e.g. half way through a given frame), the resulting time is reported as the start time of that frame. I'd be very surprised if other browsers were more accurate (despite what currentTime reports).
ok, have submitted Bug 607873 for the second thing. I don't actually agree with the first bug. None of the other browsers does rounding to nearest either and only displays 20 when 20 is actually reached. I just mentioned that because it is a visual representation of the bug.
This bug is really annoying. I have made a few projects where I'd like to sync graphics with audio play-back, and using the audio.currentTime property is clearly the best solution for doing that.
See for instance http://sonantlive.bitsnbites.eu/tool/ where the 60 FPS VU meters follow the audio.currentTime property. Both Opera and Chrome look much better than Firefox since they have better currentTime precision.
I can think of many other applications where you want to sync graphics to audio (e.g. audio visualization such as the ones usually found in media players, and demos/music "videos" with time-controlled scene switching etc).
Created attachment 545363 [details]
The problem is still present in Firefox 5.0
Silvia, Matthew : bug 669616 fixed the rounding, which is now to the nearest full second value.
Paul: bug 669616 referred to how the controls used HTMLMediaElement.currentTime, this bug refers to how often HTMLMediaElement.currentTime is updated.
I was refering to that statement kinetik wrote in comment 9 :
> The first bug is that the controls are rounding down rather than to nearest, by
> the sounds of it.
I encountered this bug a few weeks ago. It was significantly affecting the playability of my HTML5-based game. I wrote about a workaround for those who need a more accurate `currentTime` reading: http://owp.me/blog/articles/3/firefox-currenttime-problem
Created attachment 8520583 [details]
The bug is still present in Firefox 33.0
According to a report on twitter (via asa), this applies to both <audio> and <video> elements, which makes syncing animation via requestAnimationFrame (60fps) and media elements tricky. Also, what do Chrome/Safari/Edge do here?
Needs triage. Might be an easy fix, might be a tradeoff of frequency vs overhead.
This always has been an issue. We should probably align with other issues, I don't really see why we wouldn't do that.
Paul, do you have a feel for the priority on this? Is this something that should be looked at soon?
It's probably not very complex, but it's been 7 years though and people now use the Web Audio API for that kind of things. Probably not very important.
Since it has been triaged the NI to :drno is not needed. I am removing it. Feel free to restore it if you still need an answer.