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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007

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

No; in the looping case, the *sound duration* is infinite (i.e. until stop() is
called to schedule an end).

I think we're getting confused with the term "duration" because there are two
different meanings:  
    1) "duration of playing some sound" - i.e. from start() to stop() schedule
points, and  
    2) "loop duration" - the time between the loop begin point and the loop end
point.

Right now, Webkit/Blink is treating the duration parameter as #1 when not
looping, and as #2 when looping.  Firefox is treating the duration parameter as
#1 when not looping, and ignoring it entirely when looping.  (True, Ehsan?)

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

I don't agree that that is true;  the spec does not say "duration only applies
when looping," it just doesn't clearly describe how it interacts with
loopStart/loopEnd.

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

The only thing 4.10.3 is clear about is where the loop begin and end points are
set in the looping pattern, not how long you continue to play; that is set by
stop(), or by the implicit stop() that Joe was referring to that is implied in
the non-looping case by the duration parameter.

One could make a case that the Webkit/Blink's behavior is correct - that the
duration refers to the loopEnd - though this is not clearly specified, and I
think a main argument for it (aside from "that's what Webkit and Blink do
already") is that we didn't used to have loopStart/loopEnd, and this was how
you set up a loop.  That's (obviously) not a super-strong argument.

I think it makes more sense to consider (and change the spec to clarify, and
change current implementations including Blink to reflect) that duration sets
up an implicit stop() call, and interacts with looping in the obvious way.  

I think saying the duration parameter is ignored when looping is less intuitive
than either of the aforementioned options.

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

Well, it used to work like that (no loop start), and that's EXACTLY why
Webkit/Blink work the way they do.  QED.  :)

However, having an "attack segment" is a very common feature, it's nice to
have, and "duration" doesn't need to be redundant; it can be a shortcut for
calling stop().

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

I have little compatibility concern about making loops (which are relatively
recent, and moderately esoteric) start actually working when loopStart is set
but loopEnd is not.  I expect the occurrence of this in the wild is zero, to be
frank.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 19 August 2013 23:23:14 UTC