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 patch was mostly generated with this command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e 's/Binding::Wrap(aCx, aScope, this/Binding::Wrap(aCx, this/' -e 's/Binding_workers::Wrap(aCx, aScope, this/Binding_workers::Wrap(aCx, this/' -e 's/Binding::Wrap(cx, scope, this/Binding::Wrap(cx, this/' -i ""
plus a few manual fixes to dom/bindings/Codegen.py, js/xpconnect/src/event_impl_gen.py, and a few C++ files that were not caught in the search-and-replace above.
The subsample alignment of resampled buffers provides seamless playback even
when buffer durations are not an integer number of track ticks.
--HG--
extra : rebase_source : 0fcd52e8a9560de881aa73931cf22a02f984d748
The resampling filter means that the buffer influences a greater number of
samples than indicated by just its length. Including the full influence of
the linear filter means that adjacent buffers aligned appropriately will
behave as if they were one extended buffer.
The buffers are not yet aligned more carefully than track ticks, so buffers
play back seamlessly only if their sample rates and lengths are such that
their duration is an integer number of track ticks.
Knowing how far the filter extends before the start time requires
initializing the resampler before buffer processing.
The patch also includes the input latency in the first resampler input
buffer sample count estimate to reduce the number to calls required
to start the resampler.
--HG--
extra : rebase_source : 16d5af79bc5621be830f5956b51f7ff59d490575
As a side-effect, the buffer playback will now continue from the same buffer
sample number (even when looping), where possible, in the following situations:
* Changing the loop start or end parameters.
* Changing the buffer to one of a different sample rate.
--HG--
extra : transplant_source : 2%11%7Dm%92pu%60%E3G%D4%D4%DB0%2B%20%9A%1Bd%FA
The playing ref now only exists while there is a buffer.
We don't currently dispatch ended events when there is no buffer.
--HG--
extra : transplant_source : Ba%0BRD%89%96%99%F14%B6%40%3D%B2%C1%D5%28%D6%15%12
There is a change in behaviour re the offset parameter when changing the
buffer while playing to one with a different sample rate, but I'm not clear
that what we current do with mPosition in that situation is best anyway. I
think the main thing is to ensure playback from the same place if the buffer
is changed to one with the same sample rate.
--HG--
extra : transplant_source : %17%40%15%12L%9E%05et%C2o%BE%15%D7%C7%F4%ED%5E%24q
Storing references on the AudioContext instead of on the AudioNodes will allow
the AudioContext to report them to the cycle collector until offline rendering
starts.
--HG--
extra : transplant_source : %13%87%97%9F%CD%D8V%16%D2%D4%B5%84D%0A%D6%02%9BNj%FC
