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

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

--- Comment #10 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to comment #9)
> > 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.

OK, so I'll take this as a historical note then.  :-)

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

Great!

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

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.

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

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.

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

My proposal is that it should be completely ignored in the looping case. 
Ideally we should rename it to nonLoopingPortion to clear up all confusions.
;-)

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

I actually think it makes sense to not accept the cases where
loopStart>loopEnd, including the case you mentioned above.  Why do you think
that's goofy?

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

Received on Wednesday, 4 September 2013 15:23:50 UTC