- From: Chris Wilson <cwilso@google.com>
- Date: Wed, 22 Jan 2014 10:33:15 -0800
- To: "public-audio@w3.org" <public-audio@w3.org>, Raymond Toy <rtoy@google.com>
- Message-ID: <CAJK2wqVFuQ-dujK-_Zkt4CJzqgx8yr9hTkJPOMhfYp8yyPZObQ@mail.gmail.com>
Do we want to do that, or just throw an exception when start() is called when there's no buffer set (or something like that)? On Tue, Jan 21, 2014 at 5:40 PM, Karl Tomlinson < karlt+public-audio@karlt.net> wrote: > Raymond Toy writes: > > > Consider this: > > > > c = new webkitAudioContex(); > > s = c.createBufferSource(); > > s.connect(c,destination); > > c.decodeAudioData(data, function () { s.buffer = data }); > > s.start(0); > > > > Let's say decodeAudioData takes 10 sec to decode. What is supposed to > > happen here? > > Reading the current spec, I would have expected/guessed start() > would set the start time to the time at the call to start(). When > the buffer is set later, it would start playing at an offset equal > to the elapsed time since start() was called. If this > interpretation were used, some other means would be required to > defeat iOS user interaction requirements: setting playbackRate to > 0 temporarily, perhaps. Requiring the UA to integrate > playbackRate even while the there is no buffer may be a little > awkward. > > Gecko, however, seems to match Webkit and Blink's old behaviour of > starting playback from the beginning of the buffer (at the time > when the buffer is set). > >
Received on Wednesday, 22 January 2014 18:33:42 UTC