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

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

--- Comment #13 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to comment #12)
> > > 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."
> 
> I think that wording should be improved.  It sounds to me like it hasn't
> been touched since prior to the loopStart/loopEnd addition.

Sure, when we settle on what the definition should be.  ;-)

> > This means that durations longer than the length of the buffer are invalid. 
> 
> Invalid?   No - they just issue silence once the buffer has been completely
> iterated over.  At least, to my knowledge this isn't a throw-an-exception
> case.

No, I didn't mean that we should throw an exception in that case, I was talking
about ignoring such duration arguments, or, IOW, clamping duration down to the
length of the buffer - offset.

> > 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 independently of this, the "loop" parameter should have a tighter
> definition of when it can be changed.  (e.g. when "the buffer is acquired"
> sounds like a good time to copy that parameter too.)

Maybe, but for now let's work under the assumption that it can be changed at
will.

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

> > > 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.
> 
> Or rename it "soundPlayingDuration" and make it work as I suggested.  :)

And how would we solve the point above?

> > > 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?
> 
> Because it makes little to no sense to have a looping buffer that has data
> AFTER the loopEnd point; if you're looping, and there is an attack section,
> you would need to set the loopStart, but by default the loopEnd should just
> be the end of the buffer (because there's no way the looping algorithm is
> going to get to any buffer data after the loopEnd anyway).  However, that
> case explicitly doesn't work - you explicitly have to set the bufferEnd to
> the end of the data.  That's goofy.

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

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

Received on Wednesday, 4 September 2013 22:38:12 UTC