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

Cool. That's why I put in the qualification, "(if this is true)", so it's good to know.

I was not aware that ScriptProcessorNodes could have additional latency over the rest of the graph. Given that this is the case, it should be clarified in the spec (especially given that it will constitute an exception to .currentTime meaning "time of next sample block to be delivered by the graph"). And, of course, we do need to keep .playbackTime.

Best,

…Joe

On Apr 26, 2013, at 11:00 PM, Chris Rogers <crogers@google.com> wrote:

> 
> 
> 
> 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 attribute.
>  
> 
> Thanks,
> -Russell
> 
> 

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"