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

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

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

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

Received on Wednesday, 4 September 2013 22:57:26 UTC