587465 - audio.currentTime has low precision

Status: NEW

(Core :: Audio/Video: Playback, defect, P4)

Description

[info]

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

[info]

Attachment: Firefox 3.6.2

Comment 2

[info]

Attachment: Firefox 4.0b3

Comment 3

[info]

Attachment: Opera 10.61

Comment 4

[info]

Attachment: Chrome 5.0.375.126

Comment 5

[info]

Attachment: Opera 10.61

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

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

[info]

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

[Silvia Pfeiffer]

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

[Matthew Gregan [:kinetik]]

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

[Silvia Pfeiffer]

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

[m]

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).

Comment 12

[m]

Attachment: Firefox 5.0

The problem is still present in Firefox 5.0

Comment 13

[Paul Adenot (:padenot)]

Silvia, Matthew : bug 669616 fixed the rounding, which is now to the nearest full second value.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

Paul: bug 669616 referred to how the controls used HTMLMediaElement.currentTime, this bug refers to how often HTMLMediaElement.currentTime is updated.

Comment 15

[Paul Adenot (:padenot)]

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

[Strager Neds]

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

Comment 17

[Chris K]

Attachment: The bug is still present in Firefox 33.0

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

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

[Paul Adenot (:padenot)]

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

[Michael Froman [:mjf]]

Paul, do you have a feel for the priority on this?  Is this something that should be looked at soon?

Comment 21

[Paul Adenot (:padenot)]

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

[Alex Chronopoulos [:achronop]]

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.

Comment 23

[semiaddict]

I am also experiencing this issue in an application that syncs visual elements with the time of an audio or video element.
Unless I miss understood the Web Audio Api, it can't quite be used for such a case, as it is not aware of the actual playback time, or can it?
I am trying to push my users to use Firefox, but this issue creates a lag in the visual animations when using requestAnimationFrame to retrieve the media time.