audio.currentTime has low precision

NEW
Unassigned

Status

()

P4
normal
Rank:
39
9 years ago
2 months ago

People

(Reporter: info, Unassigned)

Tracking

unspecified
x86
All
Points:
---

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox59 wontfix, firefox60 fix-optional, firefox61 affected)

Details

(URL)

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Posted image Firefox 3.6.2
(Reporter)

Comment 2

9 years ago
Posted image Firefox 4.0b3
(Reporter)

Comment 3

9 years ago
Posted image Opera 10.61 (obsolete) —
(Reporter)

Comment 4

9 years ago
Posted image Chrome 5.0.375.126
(Reporter)

Comment 5

9 years ago
Posted image Opera 10.61
Attachment #466118 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
(Reporter)

Comment 7

9 years ago
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

9 years ago
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).

Comment 10

9 years ago
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

8 years ago
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

8 years ago
Posted image Firefox 5.0
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.

Comment 16

8 years ago
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
Component: Audio/Video → Audio/Video: Playback
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.
status-firefox59: --- → wontfix
status-firefox60: --- → fix-optional
status-firefox61: --- → affected
status-firefox-esr52: --- → wontfix
Flags: needinfo?(drno)
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?
Flags: needinfo?(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.
Flags: needinfo?(padenot)
Rank: 39
Priority: -- → P4

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.

Flags: needinfo?(drno)
You need to log in before you can comment on or make changes to this bug.