Need description of latency expectation in AudioProcessEvent

[olivierthereaux]

Originally reported on W3C Bugzilla ISSUE-17350 Tue, 05 Jun 2012 11:41:13 GMT
Reported by Philip Jägenstedt
Assigned to

Audio-ISSUE-59 (AudioProcessingEventScheduling): AudioProcessingEvent scheduling [Web Audio API]

http://www.w3.org/2011/audio/track/issues/59

Raised by: Philip Jägenstedt
On product: Web Audio API

How close to AudioContext.currentTime is AudioProcessingEvent.playbackTime expected to be when the audioprocess event is fired?

May a compliant implementation fire events arbitrarily far ahead of time in an arbitrary order? Presumably Web authors will make assumptions that the event is fired as close as possible to "now", so the spec should require this.

[joeberkovitz]

This question applies to AudioWorker also. I believe that a non-normative statement needs to be supplied in the spec which states that a UA's design goal of minimizing latency will also minimize the currentTime-playbackTime. However, there can never be any assumption that a compliant implementation won't fire events ahead of time due to the countervailing goal of also preventing buffer underrun.

[cwilso]

A better general description of what "currentTime" means in the context might be a great idea, too (i.e. currentTime updates unevenly, as the audio thread processes.)

[joeberkovitz]

Please see #625 (comment) for a relevant question on the definition of currentTime and its interaction with suspend/resume. Respond in the PR please.