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#7) by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Wed, 28 Aug 2013 17:57:45 GMT

(In reply to [comment #6](#issuecomment-24244199))
> (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.

Yeah, we're mixing up the terminology indeed!  Thanks for the clarification.

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

Yes, that's what Gecko does.  The reason that the WebKit/Blink interpretation is wrong IMO is that #2 already _has_ a precise definition, loopEnd-loopStart.

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

OK, I think I see the source of our disagreement now.  When reading the spec, since #2 is precisely defined, I interpret the duration argument to only reflect as #1.  If I'm understanding your viewpoint correctly (and please correct me if I'm wrong), you're trying to reconcile #2 with loopEnd-loopStart.  My contention is that those two are impossible to reconcile, since they can be different values, and the implementation has to pick one or the other.  Given the prose for section 4.10.3, I believe the spec has clearly specified what the loop duration is.

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

Yes, I agree.  The duration in the sense of #1 in the looping case is only determined by when stop() is called.

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

Agreed.  :-)

One thing to note here is that I actually have very little interest on which implementation's behavior we end up adopting.  I just think that the WebKit/Blink implementation doesn't make sense as it convolutes the notion of loop duration (which is defined as loopEnd-loopStart with the duration argument passed to start()), and I don't think you can reconcile those two.

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

You mean both in the looping and non-looping case?

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

Well, the reason I don't think that is a good idea is that in the non-looping case, the duration argument can't (shouldn't?) be longer than the length of the buffer - offset.  However, that clearly makes little sense in the looping case.  Also, note that when processing a start() call, the implementation has no idea whether it's going to be looping or not (yikes!)

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

See above.  :-)

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

That's great!  At least it gives us the altitude to fix things.  Now only if we knew what the right fix was!  ;-)

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