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#5) by Chris Wilson on W3C Bugzilla. Mon, 19 Aug 2013 23:23:13 GMT

(In reply to [comment #5](#issuecomment-24244189))
> > 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.".

No; in the looping case, the *sound duration* is infinite (i.e. until stop() is called to schedule an end).

I think we're getting confused with the term "duration" because there are two different meanings:  
    1) "duration of playing some sound" - i.e. from start() to stop() schedule points, and  
    2) "loop duration" - the time between the loop begin point and the loop end point.

Right now, Webkit/Blink is treating the duration parameter as #1 when not looping, and as #2 when looping.  Firefox is treating the duration parameter as #1 when not looping, and ignoring it entirely when looping.  (True, Ehsan?)
 
> > 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.  

I don't agree that that is true;  the spec does not say "duration only applies when looping," it just doesn't clearly describe how it interacts with loopStart/loopEnd.
 
> 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.

The only thing 4.10.3 is clear about is where the loop begin and end points are set in the looping pattern, not how long you continue to play; that is set by stop(), or by the implicit stop() that Joe was referring to that is implied in the non-looping case by the duration parameter.

One could make a case that the Webkit/Blink's behavior is correct - that the duration refers to the loopEnd - though this is not clearly specified, and I think a main argument for it (aside from "that's what Webkit and Blink do already") is that we didn't used to have loopStart/loopEnd, and this was how you set up a loop.  That's (obviously) not a super-strong argument.

I think it makes more sense to consider (and change the spec to clarify, and change current implementations including Blink to reflect) that duration sets up an implicit stop() call, and interacts with looping in the obvious way.  

I think saying the duration parameter is ignored when looping is less intuitive than either of the aforementioned options.

> 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.

Well, it used to work like that (no loop start), and that's EXACTLY why Webkit/Blink work the way they do.  QED.  :)

However, having an "attack segment" is a very common feature, it's nice to have, and "duration" doesn't need to be redundant; it can be a shortcut for calling stop().

> > 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?

I have little compatibility concern about making loops (which are relatively recent, and moderately esoteric) start actually working when loopStart is set but loopEnd is not.  I expect the occurrence of this in the wild is zero, to be frank.

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