It's too difficult to maintain, obsolete and also it duplicates the
functionnality of wpt.
Differential Revision: https://phabricator.services.mozilla.com/D3791
--HG--
extra : rebase_source : 2ccc77b285c41835e1675713c2cc126d93cfd458
extra : histedit_source : cefb7f2953974f33517e5d9ce4d8512ff4504ebe
Per spec, it should throw. This is tested in WPT.
MozReview-Commit-ID: InzdbPQM6HD
Differential Revision: https://phabricator.services.mozilla.com/D4102
--HG--
extra : rebase_source : 93375f207421da4516602d6cf906646f46d1e231
extra : intermediate-source : 99c42ce2ef78153de0833290359754ad868e8880
extra : source : a4f09a4ad0dc6674c63e3e472124982dbeee119e
extra : histedit_source : 336aa11195357051231258fe829fc48a29defe48
Ramps now take into account the end of the curve as a start value for their
automation.
Differential Revision: https://phabricator.services.mozilla.com/D3792
--HG--
extra : rebase_source : 9fc040d74bfb3bfba7aaa95d4c722edf97e1c056
extra : histedit_source : a001de094b00780ec215d77dc7629ccb44080f8e
This initial implementation does twice the necessary processing for mono input,
but that will be addressed in bug 1474222.
MozReview-Commit-ID: AZQ7Zb8jEtK
--HG--
extra : rebase_source : 9feeb254217dc4e14b78cb03315fb948e3477a16
These are derived from single precision AudioParam values
and so there is little to gain from using double.
double has the disadvantage that values intended to be integer
frame counts are less likely to be integer. e.g.
(rr) print ((float)(128.0/48000.0))*48000.f
$91 = 128
(rr) print ((float)(128.0/48000.0))*48000.0
$92 = 127.99999862909317
(rr) print ((float)(128.0/44100.0))*44100.f
$93 = 128
(rr) print ((float)(128.0/44100.0))*44100.0
$94 = 127.99999765120447
(rr) print ((float)(768.0/48000.0))*48000.f
$95 = 768.000061
(rr) print ((float)(768.0/48000.0))*48000.0
$96 = 768.0000364780426
(rr) print ((float)(768.0/44100.0))*44100.f
$97 = 768
(rr) print ((float)(768.0/44100.0))*44100.0
$98 = 768.00002697855234
MozReview-Commit-ID: FlmZJeBjUYY
--HG--
extra : rebase_source : 5c4f4a68383468c6afd15de43526eae42b01154b
When maxDelay was mMaxDelayTicks and these were an integer multiple of block
size, the +1 for determining oldestChunk was enough to wrap around the buffer
and find the most recent chunk, which may have a different channel count to
that of the oldest.
MozReview-Commit-ID: KakFeGzuvsW
--HG--
extra : rebase_source : 51c2ab1dffb7ffa9e941b06e379eacacfaa6904a
This also returns to using a single convolver for processing of mono input,
which introduces complexity in up-mixing the state of the convolver when a
second channel is added.
MozReview-Commit-ID: KeBrAswQbtF
--HG--
extra : rebase_source : d793bd967e0291069e4e6cc418de53c4b4cf3253
Note that right now aBuffer.Obj() will never be a cross-compartment wrapper anyway, because that can only happen when we're calling a WebIDL constructor, and this is not a constructor.
This results in a speed improvement of about 6% on the "Convolution reverb"
webaudio-benchmark (measured with Linux x86_64 build on Skylake).
MozReview-Commit-ID: 94W6h3qE1tB
--HG--
extra : rebase_source : f6fe4f3fa0338a90a1e389450134027d9389af09
Both for mochitest (simply an expectation adjustment), and in mochitest (align
with the code).
MozReview-Commit-ID: 2UIq4zrcd02
--HG--
extra : rebase_source : 1858e73b3ad89aade3219ee8556c653c55c85bed
This cannot happen anymore, because we're using sequence<float> and not
Float32Array in WebIDL, and sequence<float> throws when it contains Infinity or
NaN.
MozReview-Commit-ID: 9ZUbXa0viSk
--HG--
extra : rebase_source : e1783b6873caeefa1f09caf938e342f591da0056
extra : source : 5d0cce417e56935badf1e7a503f348079c8a9435
Link to the standard: https://webaudio.github.io/web-audio-api/#dom-audioparam-setvaluecurveattime
MozReview-Commit-ID: 8GwaIbQkfr2
--HG--
extra : rebase_source : aa8dd5e653de51768ff81d855fe1b8b398baa586
extra : intermediate-source : 9d34c85e0ec166fb7a117b2a85ca7cd4e98b1ceb
extra : source : d752fc72a9a35fdc0ce7b8bce94b29149eaf7639
A more involved test exists as a web-platform-tests, but we can't run it because
it makes use of AudioListener AudioParam, that we don't have right now.
MozReview-Commit-ID: 8QJ12cGVRbQ
--HG--
extra : rebase_source : 6161e33d7d8ef83eb5e16a4570a770401dd672cd
In the panning formula, one of the channels is always left untouched by the
panning gain, so the current setup didn't work: it would not apply the gain to
one of the channels.
MozReview-Commit-ID: LjrTlTT2z9r
--HG--
extra : rebase_source : 29aabddc7caf16427330687acbab91f9c3047d32
