search

soundcloud / areweplayingyet

html5 audio benchmarks
BSD 2-Clause "Simplified" License
311 stars 69 forks source link

timeupdate interval #21

Closed paulirish closed 13 years ago

paulirish commented 13 years ago

http://areweplayingyet.org/support-consistent-timeupdate-interval

WebKit fires timeupdate at 4Hz (250ms) so a 1ms hiccup during event dispatching will make Chrome/Safari fail the test.

Duplicating the test we get..

251 250 252 250 225 249

yvg commented 13 years ago

Ohai Paul! I understand the issue, but as this is a cross-platform targeted test, I think browser vendors should work on making this pass, not the opposite.

tsenart commented 13 years ago

Hey Paul!

The event dispatching time is something to consider but the big problem is that we were seeing intervals of up to 600ms (Chrome and Safari) from time to time. Probably the GC was causing them.

eric-carlson commented 13 years ago

The event dispatching time is something to consider but the big problem is that we were seeing intervals of up to 600ms (Chrome and Safari) from time to time. Probably the GC was causing them.

This is exactly the issue. I experimented with decreasing interval of the timer that is used to post the 'timeupdate' event and even when it is set to a very small value this test sometimes "fails" because GC kicks in or a layout happens. I don't think this

tsenart commented 13 years ago

@eric-carlson: I start to wonder if this specific test is of any value. For animations this callback is totally unreliable anyway (too low call rate). We're better off to use requestAnimationFrame and read the audio.played values to do custom progress animations.

tsenart commented 13 years ago

We decided to remove this test from the test suite. After some thinking we realized that it was of little value.