Behavior of events scheduled in the past?

[rtoy]

The spec doesn't say much about this, but what is supposed to happen if you schedule an event in the past? Say currentTime = 1 sec, and you scheduled something at time 0.9. What should happen.

I'm inclined to say that behavior is undefined if the time parameter to the event is in the past.

[pendragon-andyh]

What happens if the specified time is just 0.000025 seconds in the past for
the SetValueAtTime, SetTargetAtTime, SetValueCurveAtTime or
CancelScheduledValues methods?

This is potentially possible even if you do "param.SetValueAtTime(1,
ac.CurrentTime)" because the clock could easily tick between reading the
CurrentTime and calling the scheduling method.

I think it would be safer for the scheduling method to use
"Min(specifiedTime, ac.CurrentTime)". You may even have to take latency
into account because whatever you are scheduling cannot start to take
effect until the start of the next audio-frame.

On 5 February 2016 at 00:02, rtoy notifications@github.com wrote:

The spec doesn't say much about this, but what is supposed to happen if
you schedule an event in the past? Say currentTime = 1 sec, and you
scheduled something at time 0.9. What should happen.

I'm inclined to say that behavior is undefined if the time parameter to
the event is in the past.

—
Reply to this email directly or view it on GitHub
#713.

[rtoy]

You probably meant max instead of min. I think, in chrome, you can start scheduling in the current rendering quantum depending on when the call is made and when the processing of the particular audioparam is done.

It's always been an integral part of WebAudio that if you want sample accurate behavior, you must schedule things sufficiently far into the future.

[mdjp]

resolve to clamp to current time

[joeberkovitz]

I like the idea for clamping to ac.currentTime as a floor. Similar to what happens with start() etc.

[rtoy]

In PR #849, only a few of the automation methods were specified as clamping the time to the current time. I'm guessing this is an oversight. I think the intent was to clamp the time for all automation methods.