- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 Sep 2013 23:00:05 +0000
- To: public-audio@w3.org
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