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

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

--- Comment #7 from Joe Berkovitz / NF <joe@noteflight.com> ---
(In reply to comment #6)
> 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.  

For my part, I feel that Webkit/Blink's behavior (which I was unaware of and
have never tested) seems like an over-eager interpretation of "duration".

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

A loop start point is much more than "nice to have". It is the normal way that
modern instrument sample libraries are constituted. Without it, one has to
hand-stitch loops together in an arbitrary-length AudioBuffer.

This need is cited in the Use Cases document under "2.5 Music Creation
Environment with Sampled Instruments".

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

I share Chris's lack of concern for compatibility here, since a loopEnd == 0
will not produce any looping at all in today's API releases. I propose that
loopEnd == 0 have the semantics of indicating that the loop ends at the buffer
end. This removes the problem of needing to set both loopStart and loopEnd, if
that is a problem.

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

Received on Tuesday, 20 August 2013 11:57:05 UTC