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

On Sat, Apr 27, 2013 at 2:05 AM, rl baxter <baxrob@gmail.com> wrote:

> Sorry if this is a silly question, but is
> AudioProcessingEvent.playbackTime implemented yet?  I'm not seeing it, in
> chrome.canary (just updated to latest version).  Is this a 'doh' on my
> part, or is .playbackTime still only in the spec?
>

Right now it's only in the spec, but there's a work in progress patch in
WebKit...


>
>
> On Fri, Apr 26, 2013 at 8: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
>>>
>>>
>>
>