- From: Olivier Thereaux <notifications@github.com>
- Date: Wed, 11 Sep 2013 07:29:32 -0700
- To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
- Message-ID: <WebAudio/web-audio-api/issues/71/24244163@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007#0) by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Mon, 19 Aug 2013 16:07:20 GMT (In reply to comment #0) > One reading of the optional "duration" parameter > AudioBufferSourceNode.start() is that it is a kind of syntactic sugar in > which > > node.start(startTime, offset, duration); > > behaves the same as: > > node.start(startTime, offset); > node.stop(startTime + duration, offset); Hmm, stop only accepts one argument, but yes, these should be the same in the non-looping mode. > Another view is that the duration paramter has slightly different semantics > from the stop/start delta, although exactly how it differs is unclear. > Gecko's interpretation is reflected in this WebKit bug: > > https://bugs.webkit.org/show_bug.cgi?id=111952 > which states that the duration parameter is ignored if the buffer is in loop > mode. FWIW the spec is quite clear here: <https://bugs.webkit.org/show_bug.cgi?id=111952#c2> It's just that WebKit doesn't implement what the spec requires correctly. > My feeling is that the syntactic-sugar interpretation (duration is > equivalent stop/start delta) is the cleanest, most obvious behavior and was > probably the original intention of the parameter, however objectionable the > sugar flavoring may be. Really there is no good way to reconcile the duration argument with the loopStart and loopEnd attributes, as they're multiple ways of specifying the same thing... --- Reply to this email directly or view it on GitHub: https://github.com/WebAudio/web-audio-api/issues/71#issuecomment-24244163
Received on Wednesday, 11 September 2013 14:33:07 UTC