Re: Testing the Web Audio API

On Fri, May 17, 2013 at 10:45 AM, Russell McClellan <russell@motu.com>wrote:

>
> 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.


Hmm, I'm not sure if I understand your point here.  Where is the
thread-safety issue?  The script processor node and the source node are
created right after each other, and then the source node is started, so
there is no way for the audioprocess event to be dispatched before the
source node has started.

Using ScriptProcessorNode for testing might be challenging for testing long
running graphs, but in most cases we should be fine since ideally we would
be running our tests using short buffers so the real time nature of
ScriptProcessorNode should not get in the way.  This has definitely been
our experience at Mozilla so far.


> 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.
>

Quite to the contrary, the only way to reliably test ScriptProcessorNode
itself is to use another ScriptProcessorNode.  Each audioprocess event will
be dispatched only after the input nodes have produced the specified buffer
size, which means that if you have one ScriptProcessorNode feeding into
another, which is testing its event's inputBuffer to see what the previous
node has generated, the audioprocess event on the second node cannot be
dispatched until the event on the first node has been dispatched (assuming
they're both using the same buffer size, of course.)

Testing a ScriptProcessorNode using OfflineAudioContext, however, has the
down-side of having to explicitly deal with possible latencies, by
expecting silence being injected in the input buffer to handle the latency
generated by ScriptProcessorNode.  According to the current spec for
OfflineAudioContext, doing that would be hard since we need to compute a
proper render buffer size for OfflineAudioContext in advance.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>