- From: Russell McClellan <russell@motu.com>
- Date: Fri, 17 May 2013 10:45:54 -0400
- To: <chris.lowis@bbc.co.uk>
- Cc: WebAudio <public-audio@w3.org>
On May 17, 2013, at 7:24 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote: > Firstly, ported from the Mozilla test suite is the following test: > > https://github.com/WebAudio/web-platform-tests/blob/master/webaudio/the-audio-api/the-gainnode-interface/gain-node-mozilla.html > > 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. Thanks, -Russell
Received on Friday, 17 May 2013 14:46:18 UTC