W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: [web-audio-api] Unclear semantics of duration param to AudioBufferSourceNode.start() (#71)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:30 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/71/24244177@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007#2) by Joe Berkovitz / NF on W3C Bugzilla. Mon, 19 Aug 2013 18:05:42 GMT

The spec language for "duration" reads:

"The duration parameter describes the duration of the portion (in seconds) to be played. If this parameter is not passed, the duration will be equal to the total duration of the AudioBuffer minus the offset parameter. Thus if neither offset nor duration are specified then the implied duration is the total duration of the AudioBuffer."

Looping is not mentioned anywhere in this paragraph, and "total duration of the AudioBuffer" is a fuzzy concept that might or might not take account of looping.

I do not think that a duration argument should ever force looping to take place. It still seems simplest to me to construe duration as an implicit call to stop(), otherwise we have two competing definitions of "duration", one of which has to have an ugly, fiddly definition with respect to looping.

@ChrisW, the loopStart=loopEnd=0 default does not normally cause any looping, because by default the "loop" attribute of a buffer is false. ChrisR and I had a longish conversation about this and the intent here was to preserve a legacy behavior from before loopStart/loopEnd existed, where simply setting loop=true on a buffer would loop the whole buffer. He wanted the default values in this case to be zero for both loopStart and loopEnd which seemed reasonable.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/71#issuecomment-24244177
Received on Wednesday, 11 September 2013 14:30:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC