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

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 04 Sep 2013 23:00:05 +0000
To: public-audio@w3.org
Message-ID: <bug-23007-5429-QBypSGoR1Z@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 4 September 2013 23:00:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC