W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17390] (Joe Berkovitz): Loop start/stop points

From: <bugzilla@jessica.w3.org>
Date: Wed, 12 Sep 2012 16:57:28 +0000
Message-Id: <E1TBqFk-00068q-J8@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390

--- Comment #8 from Joe Berkovitz / NF <joe@noteflight.com> 2012-09-12 16:57:28 UTC ---
Amending to reflect discussion:

no loop mode in V1
start and end == 0 implies whole-sample loop and these are default values
clamping of start/end reflctd in loop behavior not readable values
type of start/end attributes to be float to support future subsample loops
non-subsample impls to round start/end to integral values

> I've been corresponding with Chris Rogers, and we have agreed on an approach
> that defers some of his previous suggestions to a V2 API.  So here's a concrete
> spec that lines up with this thinking:
> 
> The following elements are added to the AudioBufferSourceNode interface:
> 
>     const unsigned short LOOP_ENTIRE_SAMPLE = 0;  // looping applies to entire
> sample
>     const unsigned short LOOP_START_END = 1;        // looping repeats from
> loopStart to loopEnd until stop() is called
>     // (In the future, may support other modes, e.g. exit loop and play to end
> after stop() is called
>     // or crossfade at start/end repeat boundary)
> 
>     // looping mode to be employed if the existing loop attribute is true.
> Default value is LOOP_ENTIRE_SAMPLE.
>     attribute unsigned short loopMode;
> 
>     // start and endpoints as zero-based frame offsets within AudioBuffer for
> an *inclusive* loop range.
>     // Only used if loop == true and loopMode == LOOP_START_END
>     attribute unsigned long loopStart;
>     attribute unsigned long loopEnd;
> 
> The new loopMode attribute determines the behavior of playback when the loop
> flag on the node is true.  The default value of LOOP_ENTIRE_SAMPLE preserves
> the legacy behavior of looping the entire sample. Setting loopMode to
> LOOP_START_END, however, will cause loopStart and loopEnd to drive looping
> playback as follows:
> 
> - loopStart and loopEnd are clipped to the range [0..buffer.length-1]
> - the sample frame at element [loopStart] of the underlying AudioBuffer is
> considered the successor of the element [loopEnd]. Thus the playback order of
> all frames in the buffer is taken as [0..loopEnd-1], [loopStart..loopEnd-1],
> [loopStart..loopEnd-1], ...
> - if playback is attempted at an offset at loopEnd or greater by a call to
> startGrain(), no playback occurs
> - if stop() is called, output from the node ceases at the requested time
> regardless of what sample frame offset is being rendered
> 
> Note that loopStart/loopEnd are integral frame offsets in the buffer, not time
> offsets in seconds. That's because loops are really properties of the wave data
> in the underlying buffer, which makes them independent of playbackRate and thus
> not defined in terms of temporal units. Changing the playbackRate of a sample
> with loop points will alter the pitch of the sample, but not the nature of its
> loop.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are on the CC list for the bug.
Received on Wednesday, 12 September 2012 16:57:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 September 2012 16:57:30 GMT