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

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

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

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