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:41 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/71/24244278@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007#15) by Chris Wilson on W3C Bugzilla. Wed, 04 Sep 2013 23:00:05 GMT

(In reply to [comment #14](#issuecomment-24244267))
> > 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.

I don't understand why you're saying the stop() analogy does not hold, and I certainly disagree that duration as that analogy cannot be self-consistent.

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

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