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#15) by Chris Wilson on W3C Bugzilla. Wed, 04 Sep 2013 23:00:05 GMT

(In reply to [comment #14](#issuecomment-24244267))
> > 1. There is a question of whether "the length of time the buffer source will
> > play" makes sense as a definition for duration. I think that this does make
> > sense on its face, because for any length of time in a single call to
> > start(startTime, ..., duration) the user can make an equivalent pair of
> > calls to start(startTime, ...) followed by stop(startTime + duration). This
> > is a completely reasonable definition of "length of time the source will
> > play" and introduces no new concepts beyond those that predated the
> > introduction of the optional duration argument, namely start time and stop
> > time.
> 
> No, this is not as easy as it seems, since then you need to solve the
> problem of whether this should apply to the looping case or not, and then
> you'd hit the problem that I've been trying to explain.  I think the only
> self-consistent proposal is to ignore the duration parameter in the looping
> case.  I hope I've constructed an acceptable argument in favor of it.  And
> that means that the stop() analogy will no longer hold.

I don't understand why you're saying the stop() analogy does not hold, and I certainly disagree that duration as that analogy cannot be self-consistent.

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