[Bug 17378] (AudioBufferSourceNodePlaybackRate): AudioBufferSourceNode.playbackRate not strictly defined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17378

Joe Berkovitz / NF <joe@noteflight.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joe@noteflight.com

--- Comment #4 from Joe Berkovitz / NF <joe@noteflight.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 2 August 2013 15:21:40 UTC