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/ > > One solution would be to allocate one AudioBufferSourceNode for each chunk > and pre-schedule the startTime of each. One downside here is the > floating-point inaccuracy problems mentioned by Kevin. Another is the > complexity required of the page author managing a large number of nodes and > calculating start and end times for each. > > An alternate solution would be a hypothetical AudioBufferQueueNode, where > AudioBuffers could be appended to the node and discarded after they've > played. > > -Jer >
Received on Tuesday, 18 June 2013 17:25:16 UTC