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, 29 Aug 2012 21:18:02 +0000
Message-Id: <E1T6peE-0000NR-PQ@jessica.w3.org>
To: public-audio@w3.org

--- Comment #6 from Joe Berkovitz / NF <joe@noteflight.com> 2012-08-29 21:18:02 UTC ---
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
    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

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, 29 August 2012 21:18:04 UTC

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