[Bug 23007] Unclear semantics of duration param to AudioBufferSourceNode.start()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007

--- Comment #9 from Chris Wilson <cwilso@gmail.com> ---
(In reply to comment #8)
> 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 28 August 2013 18:33:13 UTC