This exposes BaseAudioContext.listener, which is a container for
parameters related to the configuration of an actual "listener" in 3D
space.
(cherry picked from commit 2a98f2a12d5069a2189fa38b4a7e158d84ee03ec)
Move the pending promises list from AudioContext to BaseAudioContext and
deal with all remaining FIXMEs.
(cherry picked from commit 2df3488840ccf8e8c560bde4826897c2023dbe29)
That helps to pass WPT tests
under /webaudio/the-audio-api/the-gainnode-interface/ctor-gain.html
(cherry picked from commit 4998385c7aeae21939f4ea24bb4f8c6eb477840b)
We need these steps to be available for the yet to be implemented
`BaseAudioContext.decodeAudioData()`.
(cherry picked from commit 177e5210e09ee4b5906e5d7db34154fae4ec76c6)
This is called by https://athenacrisis.com/ and passed through to
AudioNode.connect, which expects an AudioNode.
Implement this function enough so that we return an AudioNode so that
AudioNode.connect does not throw a TypeError.
(cherry picked from commit a51095f705c5a6bce2c291e8b51ac90182c63419)
I can't actually spot in the spec where it explicitly says to pass this
through (unlike the AudioContext constructor) - but clearly this needs
to be passed through for an OfflineAudioContext to actually have a
sample rate!
Which currently will always throw an exception as it is unimplemented
under the hood - but this gives all of the plumbing we need in order to
create a oscillator node as used in the reduced turnstyle testcase.
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
The spec doesn't tell us the exact value to use, but a minumum & maximum
range of supported values. Just to be consistent with another browser,
we follow the values that firefox appears to support from testing the
interface on my machine.
This function will be used in the AudioBuffer constructor, but is
defined in the spec as part of BaseAudioContext.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
