The numberOfChannels array on AudioBuffer is now an infallible array, as this
is considerably smaller than infallible channel data array allocations in
AllocateAudioBlock and similar to channel data pointer array allocations in
AudioChunk.
--HG--
extra : transplant_source : C%29_%13%9C%9C%A1%E1%A3%E8%C9_%93%11%85lM%FC%7E%BC
This patch was mostly generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e '/WrapObject(JSContext/ {; N; s/\(WrapObject(JSContext *\* *a\{0,1\}[Cc]x\),\n\{0,1\} *JS::Handle<JSObject\*> a\{0,1\}[sS]cope/\1/ ; }' -i ""
and then reverting the changes that made to
dom/bindings/BindingUtils.h, since those WrapObject methods are not
the ones we're trying to change here, plus a bunch of manual fixups
for cases that this command did not catch (including all the callsites
of WrapObject()).
This is a mega-patch that was too hard to disentangle. Here's what it does:
-- Create infrastructure around AudioNode::UpdateOutputEnded to detect
when a node can no longer produce any output. When that becomes true,
disconnect it from the AudioNode graph.
-- Have AudioNode implement JSBindingFinalized to use as input in
UpdateOutputEnded.
-- Give every AudioNode a MediaStream, and give every connection
a MediaInputPort.
-- Actually play the audio that reaches the AudioContext's destination node.
-- Force AudioContext to use the audio sample rate defined by MediaStreamGraph.
-- Fix AudioBufferSourceNode's start and stop methods to possibly throw and
take default 'when' parameters.
-- Create an AudioNodeStream for AudioBufferSourceNode and give it a
AudioBufferSourceNodeEngine that does what's needed. Set parameters for
this engine in the start() and stop() methods.
-- Create AudioBuffer::GetThreadSharedChannelsForRate, which is responsible
for stealing the contents of any JS array buffers, and bundling them up
into a thread-shared read-only buffer object which can be used as
part of an AudioChunk. This method will also be responsible for
resampling and caching as necessary.
--HG--
rename : content/media/MediaStreamGraph.cpp => content/media/MediaStreamGraphImpl.h
extra : rebase_source : 9fa0ec0efa304acd6513e427103d6339c78efa53
This is a mega-patch that was too hard to disentangle. Here's what it does:
-- Create infrastructure around AudioNode::UpdateOutputEnded to detect
when a node can no longer produce any output. When that becomes true,
disconnect it from the AudioNode graph.
-- Have AudioNode implement JSBindingFinalized to use as input in
UpdateOutputEnded.
-- Give every AudioNode a MediaStream, and give every connection
a MediaInputPort.
-- Actually play the audio that reaches the AudioContext's destination node.
-- Force AudioContext to use the audio sample rate defined by MediaStreamGraph.
-- Fix AudioBufferSourceNode's start and stop methods to possibly throw and
take default 'when' parameters.
-- Create an AudioNodeStream for AudioBufferSourceNode and give it a
AudioBufferSourceNodeEngine that does what's needed. Set parameters for
this engine in the start() and stop() methods.
-- Create AudioBuffer::GetThreadSharedChannelsForRate, which is responsible
for stealing the contents of any JS array buffers, and bundling them up
into a thread-shared read-only buffer object which can be used as
part of an AudioChunk. This method will also be responsible for
resampling and caching as necessary.
This is the full implementation of the AudioBuffer object. There are
two ways to create these objects from an audio context and this patch
implements only one of them.
The construction of the AudioBuffer object is a two step process: the
object should be created with operator new first, and then
InitializeBuffers should be called on it. InitializeBuffers is
fallible, because it uses the JS API to create the underlying typed
arrays, but that's fine, since the length of the buffers comes from web
content, and we don't want to use infallible allocations for those
anyways.
We hold on to the JS objects from the C++ implementation, and trace
through all of those objects, so that a GC does not kill those object
without us knowing.
The buffer should be possible to manipulate from both C++ and JS, and
the C++ object probably needs to support a set of methods for the C++
callers at some point.
