- From: rl baxter <baxrob@gmail.com>
- Date: Sat, 27 Apr 2013 02:05:28 -0700
- To: Chris Rogers <crogers@google.com>
- Cc: "public-audio@w3.org WG" <public-audio@w3.org>
- Message-ID: <CACo9a0fs6xiZ9xbVo_kx8B==wdxe-VgigERB=NaKA4GQ=Tj+7w@mail.gmail.com>
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? 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 >> >> >
Received on Saturday, 27 April 2013 09:05:55 UTC