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#8) by Chris Wilson on W3C Bugzilla. Wed, 28 Aug 2013 18:33:12 GMT

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

See above, "weak argument".  :)  I'm not suggesting we should keep that.

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

Not really; I'm not arguing that loop duration should be affected by the 'duration' parameter - just explaining that originally, that was how loop duration was, in fact, specified, which is why it works that way in Blink/Webkit today.

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

Yeah, I think it makes sense to not conflate loop duration and duration.

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

Yes.  In either case, I think duration sets the length of time that the buffer source will play.

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

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.  The loop start/end in the looping case let it play longer than that.

> > > > 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!  ;-)

Note there are two separate issues here -

A) what "duration" means (if anything) in the looping case, and 

B) the current definition of loopStart/loopEnd states if loopStart is set, but loopEnd is not, the loopStart is ignored.  I think that's goofy, and should be changed.

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