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: Mon, 19 Aug 2013 19:23:15 +0000
To: public-audio@w3.org
Message-ID: <bug-23007-5429-KoeaYLRtui@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007

--- Comment #4 from Chris Wilson <cwilso@gmail.com> ---
(In reply to comment #3)
> Looping is not mentioned anywhere in this paragraph, and "total duration of
> the AudioBuffer" is a fuzzy concept that might or might not take account of
> looping.

Quite true.

> I do not think that a duration argument should ever force looping to take
> place. 

No, I agree.

> It still seems simplest to me to construe duration as an implicit
> call to stop(), otherwise we have two competing definitions of "duration",
> one of which has to have an ugly, fiddly definition with respect to looping.

In other words, "duration" refers to the length of time that the source will be
sounding, whether looping or not.  I would agree with that behavior, although
I'd point out we'll need to change the definition when omitted (duration cannot
be the total duration of the AudioBuffer when omitted *while looping*- it
should infinite).

I *think* Ehsan is suggesting that duration should be completely ignored when
looping.  I'm less happy with that - I think we either should support duration
as a looping shortcut (as Webkit and Blink currently do), or we should use it
as an implicit stop() shortcut.

> @ChrisW, the loopStart=loopEnd=0 default does not normally cause any
> looping, because by default the "loop" attribute of a buffer is false.

I know that - I meant "if loop=true, it looks like a zero-length loop segment
by default".  I wasn't clear.  :)

> ChrisR and I had a longish conversation about this and the intent here was
> to preserve a legacy behavior from before loopStart/loopEnd existed, where
> simply setting loop=true on a buffer would loop the whole buffer. He wanted
> the default values in this case to be zero for both loopStart and loopEnd
> which seemed reasonable.

Certainly, if you create a new buffersource and set loop=true, defaults should
loop the whole buffer.  I'm okay with keeping those defaults (and the magic
loopEnd=0 means buffer.length), but I think it's a bit weird that the algorithm
defined means you can't set loopStart without setting loopEnd also.  I think
that should be fixed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 19 August 2013 19:23:16 UTC

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