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

Re: [web-audio-api] Loop start/stop points (#157)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:30:01 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/157/24244588@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390#5) by Joe Berkovitz / NF on W3C Bugzilla. Wed, 29 Aug 2012 21:18:02 GMT

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.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:34:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC