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#10) by Joe Berkovitz / NF on W3C Bugzilla. Wed, 04 Sep 2013 16:19:57 GMT

(In reply to [comment #10](#issuecomment-24244226))
> > Yes.  In either case, I think duration sets the length of time that the
> > buffer source will play.
> 
> OK, I am not sure if this makes sense at all.  Currently, the spec defines
> duration as following:
> 
> "The duration parameter describes the duration of the portion (in seconds)
> to be played."
> 
> This means that durations longer than the length of the buffer are invalid. 
> Now, with your definition, they _should_ be valid in the looping case.  The
> problem is that by the time that the author calls start(), we *don't* know
> whether we're in the looping case or not, so the implementation will be
> unable to do the proper check there.  In fact, in a sense we *never* know
> whether we're looping or not as the web page can keep on toggling the loop
> attribute on the main thread as the buffer is being played back.  So, I
> don't think that any proposal which assumes different meanings for the
> duration argument in the looping/non-looping case is possible to implement.

Let's break this into two issues, which I think are somewhat independent.

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.

2. Ehsan raises a good point about the effect of intervening changes to looping properties of the buffer prior to its playback. This question also exists for start/stop calls *without* duration and I propose that it should be logged as a separate API issue that belongs to the overall data-race family of questions. For that matter, the entire "buffer" property of the node could be changed on the fly, couldn't it?  My belief is that such on-the-fly changes are just as unsafe and unpredictable as changing the sample frames inside a buffer whose other attributes remain stable.

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