Re: Testing the Web Audio API

On May 17, 2013, at 7:24 AM, Chris Lowis <> wrote:
> Firstly, ported from the Mozilla test suite is the following test:
> It uses a ScriptProcessor to compare 2 buffers where the expected buffer
> has half the amplitude of the input buffer in order to test that a
> GainNode with a 'gain.value' of 0.5 behaves as expected.

The test as written isn't thread-safe.  The script processor node could trigger an onaudioprocess event to be handled before the source is even started.  Generally speaking, with all the unspecified latency concerns, it strikes me as a bad idea to use script processors for testing.  What happens if you insert a node into the graph that adds latency - such as another script processor?  The latency that it adds isn't specified, so you can't possibly write a test this way without relying on unspecified behavior.


Received on Friday, 17 May 2013 14:46:18 UTC