1,295
edits
User:Roc/AudioBufferProposal: Difference between revisions
Jump to navigation
Jump to search
→Specification Changes
| Line 21: | Line 21: | ||
# Attach <tt>ArrayBuffer</tt>s containing copies of the data to the <tt>AudioBuffer</tt>, to be returned by the next call to <tt>getChannelData</tt>. | # Attach <tt>ArrayBuffer</tt>s containing copies of the data to the <tt>AudioBuffer</tt>, to be returned by the next call to <tt>getChannelData</tt>. | ||
''<small>Note: These are just the observable behavior. | ''<small>Note: These are just the observable behavior. <b>The entire operation can usually be implemented without copying channel data.</b> In particular, the last step should be performed lazily at the next <tt>getChannelData</tt> call (if there is one; there often won't be). That means a sequence of consecutive "acquire the contents" operations with no intervening <tt>getChannelData</tt> (e.g. multiple <tt>AudioBufferSourceNodes</tt> playing the same <tt>AudioBuffer</tt>) can be implemented with no allocations or copying.</small>'' | ||
''<small>Note: Implementations can perform an additional optimization: if <tt>getChannelData</tt> is called on an <tt>AudioBuffer</tt>, fresh <tt>ArrayBuffer</tt>s have not yet been allocated, but all invokers of previous "acquire the contents" operations on an <tt>AudioBuffer</tt> have stopped using the <tt>AudioBuffer</tt>'s data, the raw data buffers can be recycled for use with new <tt>AudioBuffer</tt>s, avoiding any reallocation or copying of the channel data.</small>'' | ''<small>Note: Implementations can perform an additional optimization: if <tt>getChannelData</tt> is called on an <tt>AudioBuffer</tt>, fresh <tt>ArrayBuffer</tt>s have not yet been allocated, but all invokers of previous "acquire the contents" operations on an <tt>AudioBuffer</tt> have stopped using the <tt>AudioBuffer</tt>'s data, the raw data buffers can be recycled for use with new <tt>AudioBuffer</tt>s, avoiding any reallocation or copying of the channel data.</small>'' | ||