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#14) by Chris Wilson on W3C Bugzilla. Wed, 04 Sep 2013 22:57:25 GMT

(In reply to [comment #13](#issuecomment-24244257))
> > > Consider what should happen when you have a buffer of 1s, and pass in 2s as
> > > the duration with loop==false, then call start() and in about 1.5s, you set
> > > loop=true.  Should the implementation play the buffer for the first second,
> > > then produce silence for half a second, and then jump back somewhere in the
> > > middle of the buffer and start playing back?  That sound insane to me, and
> > > I'd be quite strongly opposed to that.
> > 
> > I would expect the onended would have fired and the memory potentially
> > reclaimed already, so no, I wouldn't expect that.
> 
> This directly contradicts with your earlier suggestion:
> 
> "The duration certainly CAN be longer than the buffer (length-offset) in the
> non-looping case - it will just be silent after it runs out of bits."
> 
> You should pick one behavior or the other, as they're contradictory.

No, I don't believe that they are, as I didn't mean that latter literally; I meant it in response to your implicit suggestion this was an error (invalid).  I see hitting the end of the buffer and the end of playback, according to the current settings:
1) single-shot playback, bufferlength is reached, or 
2) single-shot playback, duration is reached

to cause the buffersource to no longer be active, and as per design constraints, it cannot be "revived".  In old parlance, it's FINISHED_STATE.  It's done.  I would likely expect onEnded to fire, for example, not after duration, but after playback is done.

> Well, loopStart and loopEnd are both attributes on the object, what should
> the following code observe?
> 
> console.log(node.loopEnd); // 0
> node.loopStart = 10;
> console.log(node.loopEnd); // ???
> 
> It is very weird to have assinging to loopStart suddenly change loopEnd.
> 
> Your suggestion would be OK if these were just internal state, but
> unfortunately they're not.  (And yes, this is bad API design, a better API
> would be something like: |void loop(double loopStart, optional double
> loopEnd);| and then we wouldn't have this problem. :(

Huh?  I would expect the log above to issue
0
0
loopEnd doesn't get assigned by the assignment of loopStart - it's an input attribute, not a reflection of internal state.  Otherwise that first log shouldn't show zero either - it should show bufferLength, since if loopStart is unassigned, it will play through as if loopEnd were set to the length of the buffer (i.e, loop the entire buffer).  I would not, in short, expect assigning loopStart to change loopEnd.

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