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

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

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

No, this is not as easy as it seems, since then you need to solve the problem
of whether this should apply to the looping case or not, and then you'd hit the
problem that I've been trying to explain.  I think the only self-consistent
proposal is to ignore the duration parameter in the looping case.  I hope I've
constructed an acceptable argument in favor of it.  And that means that the
stop() analogy will no longer hold.

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

They're not unsafe at all, they're unpredictable, but Web Audio as a whole has
that property pretty much everywhere, since it allows changing the structure of
the graph as playback is in progress.  I think it's futile to try to fix that
in this one case.

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

Received on Wednesday, 4 September 2013 22:42:21 UTC