W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Re: [Bug 20698] Need a way to determine AudioContext time of currently audible signal

From: Chris Rogers <crogers@google.com>
Date: Fri, 26 Apr 2013 20:00:40 -0700
Message-ID: <CA+EzO0k38cp9dHSQHDy0nXEsY7wYY1xuO1+Arc8fxHLSXHC2-Q@mail.gmail.com>
To: Russell McClellan <russell@motu.com>
Cc: "public-audio@w3.org WG" <public-audio@w3.org>
On Fri, Apr 26, 2013 at 1:29 PM, Russell McClellan <russell@motu.com> wrote:

> On Apr 25, 2013, at 1:18 PM, bugzilla@jessica.w3.org wrote:
> > - Corollary: need to document (if this is true) that currentTime advances
> > monotonically by a time quantum equal to the block size, as each block is
> > synthesized.  This is important because if true it implies that
> > ScriptProcessingNode JS code may consult currentTime instead of
> > event.playbackTime, and that the latter is no longer needed since it's
> always
> > equal to currentTime.
> As a developer, I don't understand this idea at all.  ScriptProcessorNodes
> may (and do in all current implementations) have additional latency above
> and beyond the rest of the audio graph.  That is, the global "block
> currently being processed" (whatever that means) will in general not have
> any defined relationship to the playback time of the current script
> processor block.  Doing as you suggest here would make it impossible for
> developers to synchronize javascript processing to other audio graph
> processing.

Russell is quite right here, so that's why we have the .playbackTime

> Thanks,
> -Russell
Received on Saturday, 27 April 2013 03:01:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC