On Jun 18, 2013, at 10:24 AM, Chris Rogers <crogers@google.com> wrote: > > > > On Tue, Jun 18, 2013 at 8:55 AM, Jer Noble <jer.noble@apple.com> wrote: > > On Jun 18, 2013, at 6:55 AM, Joe Berkovitz <joe@noteflight.com> wrote: > >> Actually, as co-editor of the use case document I am very interested in understanding why the arbitrary concatenation of buffers is important. When would this technique be used by a game? Is this for stitching together prerecorded backgrounds? >> > > Here's a good example of such a use case: http://labs.echonest.com/Uploader/index.html > > The WebAudio app slices an uploaded piece of music into discrete chunks, calculates paths between similar chunks, and "stitches" together an inifintely long rendidion of the song by jumping in the timeline between similar chunks. > > This app is currently implements its queueing model by calling setTimeout(n), where n is 10ms before the anticipated end time of the current sample. However, this causes stuttering and gaps whenever the timer is late by more than 10ms. WebKit Nightlies implement JavaScript timer coalescing when pages are not visible, which has lead the Infinite Jukebox page to pause playback when it gets a 'visibilitychange'/'hidden' event. > > A lookahead scheduling of 10ms is a bit optimistic. Chris Wilson has written an excellent article about this topic: > http://www.html5rocks.com/en/tutorials/audio/scheduling/ > Even so, timer coalescing can delay timers by very large amounts (perhaps even 1000ms!) so even some of the techniques Chris mentions in that article will fail unless very large lookahead queues are built up. For stiching together separate AudioBuffers seamlessly, having a buffer queue node available would be much more preferable to having web authors implement their own queuing model. -Jer
Received on Tuesday, 18 June 2013 18:04:43 UTC