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#6) by Joe Berkovitz / NF on W3C Bugzilla. Tue, 20 Aug 2013 11:57:00 GMT

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

For my part, I feel that Webkit/Blink's behavior (which I was unaware of and have never tested) seems like an over-eager interpretation of "duration".

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

A loop start point is much more than "nice to have". It is the normal way that modern instrument sample libraries are constituted. Without it, one has to hand-stitch loops together in an arbitrary-length AudioBuffer.

This need is cited in the Use Cases document under "2.5 Music Creation Environment with Sampled Instruments".

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

I share Chris's lack of concern for compatibility here, since a loopEnd == 0 will not produce any looping at all in today's API releases. I propose that loopEnd == 0 have the semantics of indicating that the loop ends at the buffer end. This removes the problem of needing to set both loopStart and loopEnd, if that is a problem.

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