Last Comment Bug 587465 - audio.currentTime has low precision
: audio.currentTime has low precision
Status: NEW
Product: Core
Classification: Components
Component: Audio/Video: Playback (show other bugs)
: unspecified
: x86 All
P4 normal 39 with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Nils Ohlmeier [:drno]
Depends on:
  Show dependency treegraph
Reported: 2010-08-15 09:02 PDT by info
Modified: 2019-01-25 04:00 PST (History)
16 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Firefox 3.6.2 (17.84 KB, image/png)
2010-08-15 09:13 PDT, info
no flags Details
Firefox 4.0b3 (18.45 KB, image/png)
2010-08-15 09:14 PDT, info
no flags Details
Opera 10.61 (39.76 KB, image/png)
2010-08-15 09:15 PDT, info
no flags Details
Chrome 5.0.375.126 (88.91 KB, image/png)
2010-08-15 09:17 PDT, info
no flags Details
Opera 10.61 (46.97 KB, image/png)
2010-08-15 09:21 PDT, info
no flags Details
Firefox 5.0 (19.23 KB, image/png)
2011-07-12 05:07 PDT, m
no flags Details
The bug is still present in Firefox 33.0 (197.62 KB, image/png)
2014-11-11 03:38 PST, Chris K
no flags Details

Description User image info 2010-08-15 09:02:47 PDT
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.

Reproducible: Always

Steps to Reproduce:
1. Create an <audio> element
2. Play
3. Listen to currentTime values
Actual Results:  
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).

Expected Results:  
audio.currentTime should report a different value (incremental) every frame, and the visualisations should be mainly green squares.
Comment 1 User image info 2010-08-15 09:13:15 PDT
Created attachment 466116 [details]
Firefox 3.6.2
Comment 2 User image info 2010-08-15 09:14:50 PDT
Created attachment 466117 [details]
Firefox 4.0b3
Comment 3 User image info 2010-08-15 09:15:21 PDT
Created attachment 466118 [details]
Opera 10.61
Comment 4 User image info 2010-08-15 09:17:21 PDT
Created attachment 466119 [details]
Chrome 5.0.375.126
Comment 5 User image info 2010-08-15 09:21:52 PDT
Created attachment 466121 [details]
Opera 10.61
Comment 6 User image Chris Pearce [:cpearce (GMT+13)] 2010-08-15 12:36:39 PDT
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.
Comment 7 User image info 2010-08-15 14:42:51 PDT
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)
Comment 8 User image Silvia Pfeiffer 2010-10-27 21:43:18 PDT
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.
Comment 9 User image Matthew Gregan [:kinetik] 2010-10-27 21:59:18 PDT
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).
Comment 10 User image Silvia Pfeiffer 2010-10-27 22:46:00 PDT
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.
Comment 11 User image m 2011-07-11 00:29:05 PDT
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 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).
Comment 12 User image m 2011-07-12 05:07:59 PDT
Created attachment 545363 [details]
Firefox 5.0

The problem is still present in Firefox 5.0
Comment 13 User image Paul Adenot (:padenot) 2011-07-15 03:43:56 PDT
Silvia, Matthew : bug 669616 fixed the rounding, which is now to the nearest full second value.
Comment 14 User image Chris Pearce [:cpearce (GMT+13)] 2011-07-15 12:57:45 PDT
Paul: bug 669616 referred to how the controls used HTMLMediaElement.currentTime, this bug refers to how often HTMLMediaElement.currentTime is updated.
Comment 15 User image Paul Adenot (:padenot) 2011-07-15 13:01:12 PDT
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.
Comment 16 User image Strager Neds 2011-08-16 22:22:03 PDT
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:
Comment 17 User image Chris K 2014-11-11 03:38:07 PST
Created attachment 8520583 [details]
The bug is still present in Firefox 33.0
Comment 18 User image Randell Jesup [:jesup] (needinfo me) 2018-03-17 05:51:25 PDT
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.
Comment 19 User image Paul Adenot (:padenot) 2018-08-21 02:27:55 PDT
This always has been an issue. We should probably align with other issues, I don't really see why we wouldn't do that.
Comment 20 User image Michael Froman [:mjf] 2018-09-11 10:29:56 PDT
Paul, do you have a feel for the priority on this?  Is this something that should be looked at soon?
Comment 21 User image Paul Adenot (:padenot) 2018-09-12 05:34:07 PDT
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.
Comment 22 User image Alex Chronopoulos [:achronop] 2019-01-25 04:00:59 PST
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.

Note You need to log in before you can comment on or make changes to this bug.