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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007#4) by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Mon, 19 Aug 2013 22:53:35 GMT

(In reply to [comment #4](#issuecomment-24244183))
> > 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.
> 
> In other words, "duration" refers to the length of time that the source will
> be sounding, whether looping or not.  I would agree with that behavior,
> although I'd point out we'll need to change the definition when omitted
> (duration cannot be the total duration of the AudioBuffer when omitted
> *while looping*- it should infinite).

That would not make sense in the looping case because "If this parameter is not passed, the duration will be equal to the total duration of the AudioBuffer minus the offset parameter.".

> I *think* Ehsan is suggesting that duration should be completely ignored
> when looping.  I'm less happy with that - I think we either should support
> duration as a looping shortcut (as Webkit and Blink currently do), or we
> should use it as an implicit stop() shortcut.

I'm not suggesting that per se, all I'm saying is that is what the spec has required for now.  It's just sad that WebKit/Blink were never fixed according to that.  The prose under 4.10.3 is quite clear on what should happen in the case of looping, and since duration is never mentioned there, it should be ignored.  This is what Gecko implements.

If we were to write the spec today, we should have just dropped the duration argument altogether, as it is redundant.  Also I'd have dropped loopStart/loopEnd and added loopDuration or something, forcing loops to always start at the beginning of the buffer.

> > @ChrisW, the loopStart=loopEnd=0 default does not normally cause any
> > looping, because by default the "loop" attribute of a buffer is false.
> 
> I know that - I meant "if loop=true, it looks like a zero-length loop
> segment by default".  I wasn't clear.  :)
> 
> > 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.
> 
> Certainly, if you create a new buffersource and set loop=true, defaults
> should loop the whole buffer.  I'm okay with keeping those defaults (and the
> magic loopEnd=0 means buffer.length), but I think it's a bit weird that the
> algorithm defined means you can't set loopStart without setting loopEnd
> also.  I think that should be fixed.

Do you have any proposals on how to do that while not breaking compatibility with existing content?

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/71#issuecomment-24244189