1208318 - test_scriptProcessorNode_playbackTime1.html assumes that AudioContext runs on same clock as setTimeout

Status: RESOLVED FIXED

(Core :: Web Audio, defect)

Description

[Karl Tomlinson (:karlt)]

Assuming that AudioContext runs on same clock as setTimeout happens to be valid for our implementation where contexts with no nodes use a main thread clock, but better not to make this assumption.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: modify test to avoid assuming different clocks are synchronized

I think this actually makes the test stricter.
The playbackTime now matches the expected minimum each time I've run it.

Comment 2

[Paul Adenot (:padenot)]

Comment on attachment 8665757 [details] [diff] [review]
modify test to avoid assuming different clocks are synchronized

Review of attachment 8665757 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/webaudio/test/test_scriptProcessorNode_playbackTime1.html
@@ +16,5 @@
> +
> +var context = new AudioContext();
> +const delay = 0.1;
> +
> +setTimeout(

Can we use "context.onstatechange" here ? It seems more robust than waiting 100ms.

Comment 3

[Karl Tomlinson (:karlt)]

Attachment: ensure that currentTime has advanced sufficiently to easily detect failure

(In reply to Paul Adenot (:padenot) from comment #2)
> Can we use "context.onstatechange" here ? It seems more robust than waiting
> 100ms.

That could ensure the context has started, but I would also still want
something to ensure that currentTime is sufficiently > 0 to notice if
playbackTime does not include the 'extra' time.  The latter is sufficient on
its own.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/96db1aea13c6
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a6b599cc18c

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/96db1aea13c6
https://hg.mozilla.org/mozilla-central/rev/5a6b599cc18c