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 16:07:20 +0000
To: public-audio@w3.org
Message-ID: <bug-23007-5429-Q1jabvjb4Y@http.www.w3.org/Bugs/Public/>

Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> changed:

           What    |Removed                     |Added
                 CC|                            |ehsan@mozilla.com

--- Comment #1 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to comment #0)
> One reading of the optional "duration" parameter
> AudioBufferSourceNode.start() is that it is a kind of syntactic sugar in
> which
>    node.start(startTime, offset, duration);
> behaves the same as:
>    node.start(startTime, offset);
>    node.stop(startTime + duration, offset);

Hmm, stop only accepts one argument, but yes, these should be the same in the
non-looping mode.

> Another view is that the duration paramter has slightly different semantics
> from the stop/start delta, although exactly how it differs is unclear.
> Gecko's interpretation is reflected in this WebKit bug:
>   https://bugs.webkit.org/show_bug.cgi?id=111952

> which states that the duration parameter is ignored if the buffer is in loop
> mode.

FWIW the spec is quite clear here:
<https://bugs.webkit.org/show_bug.cgi?id=111952#c2>  It's just that WebKit
doesn't implement what the spec requires correctly.

> My feeling is that the syntactic-sugar interpretation (duration is
> equivalent stop/start delta) is the cleanest, most obvious behavior and was
> probably the original intention of the parameter, however objectionable the
> sugar flavoring may be.

Really there is no good way to reconcile the duration argument with the
loopStart and loopEnd attributes, as they're multiple ways of specifying the
same thing...

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

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