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

Re: [web-audio-api] (AudioBufferSourceNodePlaybackRate): AudioBufferSourceNode.playbackRate not strictly defined (#95)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:34 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/95/24244220@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17378#3) by Joe Berkovitz / NF on W3C Bugzilla. Fri, 02 Aug 2013 15:21:38 GMT

I was thinking about volunteering a patch but reached the same conclusion as Ehsan: we need to have a basic discussion first.

The basic outline of my proposal is different from Ehsan's but similar in spirit (I think):

- define an "effective sampling rate" that is the product of the playbackRate AudioParam and the base sampling rate of the underlying AudioBuffer.

(NB I would not include the effect of downstream resampling-like effects such as doppler shifts as I think this may lead to confusion over the behavior of graphs with branched routing. It seems harder for developers to predict what will happen.)

- At each sample frame, determine a buffer playback quantum that advances a notional "playback cursor" associated with the buffer. The quantum is in fractional sample frames and is (effective sampling rate) / (context sampling rate).

- Prior to starting playback the cursor is initialized to the starting offset of the buffer. When playing, the cursor advances by the playback quantum; a positive quantum moves the cursor forwards while a negative quantum moves the cursor backwards. The data window between the previous and newly updated cursor position is used to interpolate the value of the next sample frame. If the cursor moved forwards, sample frames in the window are considered in forward order; if backwards, sample frames in the window are considered in reverse order. Such interpolation may take advantage of the contents of the previously calcualted data window for the buffer [I'm not going to attempt a description of how interpolation actually works here].

- Within the loopStart/loopEnd region, the cursor can only advance by cycling through the loop forwards or backwards. The data window for resampled rendering includes the contents of these cycles.

- If prior to the loop region, the cursor cannot move backwards past offset 0 of the buffer -- i.e. the left edge of the data window is clamped to offset 0.

- If the cursor moves forwards past the end of the buffer, playback ends (I am sure the spec has better language describing this transition).

- If the cursor does not move during the rendering of a frame because the effective sampling rate is 0, then the data window starts at ends at a single point within the buffer, so the output is the single [interpolated] value at thet buffer offset. This implies that a zero playback rate will produce a DC output with the value at the current notional position of the cursor.

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

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