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

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

--- Comment #11 from Joe Berkovitz / NF <joe@noteflight.com> ---
(In reply to comment #10)
> > 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.

Let's break this into two issues, which I think are somewhat independent.

1. There is a question of whether "the length of time the buffer source will
play" makes sense as a definition for duration. I think that this does make
sense on its face, because for any length of time in a single call to
start(startTime, ..., duration) the user can make an equivalent pair of calls
to start(startTime, ...) followed by stop(startTime + duration). This is a
completely reasonable definition of "length of time the source will play" and
introduces no new concepts beyond those that predated the introduction of the
optional duration argument, namely start time and stop time.

2. Ehsan raises a good point about the effect of intervening changes to looping
properties of the buffer prior to its playback. This question also exists for
start/stop calls *without* duration and I propose that it should be logged as a
separate API issue that belongs to the overall data-race family of questions.
For that matter, the entire "buffer" property of the node could be changed on
the fly, couldn't it?  My belief is that such on-the-fly changes are just as
unsafe and unpredictable as changing the sample frames inside a buffer whose
other attributes remain stable.

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

Received on Wednesday, 4 September 2013 16:19:59 UTC