Closed Bug 1208318 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Web Audio, defect)

43 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: karlt, Assigned: karlt)

Details

Attachments

(2 files)

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.
I think this actually makes the test stricter.
The playbackTime now matches the expected minimum each time I've run it.
Attachment #8665757 - Flags: review?(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.
Attachment #8665757 - Flags: review?(padenot) → review+
(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.
Attachment #8667120 - Flags: review?(padenot)
Attachment #8667120 - Flags: review?(padenot) → review+
https://hg.mozilla.org/mozilla-central/rev/96db1aea13c6
https://hg.mozilla.org/mozilla-central/rev/5a6b599cc18c
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.