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

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

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

Yep, that was the point of the statement.

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

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

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

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

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

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

Obviously, setting loopStart > loopEnd where loopEnd != the default is fairly
nonsensical.

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

Received on Wednesday, 4 September 2013 16:56:08 UTC