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 22:53:35 +0000
To: public-audio@w3.org
Message-ID: <bug-23007-5429-64MZL7ITSR@http.www.w3.org/Bugs/Public/>

--- Comment #5 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to comment #4)
> > 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).

That would not make sense in the looping case because "If this parameter is not
passed, the duration will be equal to the total duration of the AudioBuffer
minus the offset parameter.".

> 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.

I'm not suggesting that per se, all I'm saying is that is what the spec has
required for now.  It's just sad that WebKit/Blink were never fixed according
to that.  The prose under 4.10.3 is quite clear on what should happen in the
case of looping, and since duration is never mentioned there, it should be
ignored.  This is what Gecko implements.

If we were to write the spec today, we should have just dropped the duration
argument altogether, as it is redundant.  Also I'd have dropped
loopStart/loopEnd and added loopDuration or something, forcing loops to always
start at the beginning of the buffer.

> > @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.

Do you have any proposals on how to do that while not breaking compatibility
with existing content?

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 19 August 2013 22:53:37 UTC

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