W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: [web-audio-api] Unclear semantics of duration param to AudioBufferSourceNode.start() (#71)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:39 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/71/24244267@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007#13) by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Wed, 04 Sep 2013 22:42:19 GMT

(In reply to [comment #11](#issuecomment-24244237))
> (In reply to [comment #10](#issuecomment-24244226))
> > > 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.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:34:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC