Moar API changes!

[ferjm]

Apparently a rendering thread can either be running or suspended, not closed.

The rest are exposed getters and a way to message AudioScheduledSourceNodes directly (and a generic way for a node to implement different message handlers).

r? @Manishearth

[Manishearth]

I don't think we need getters for properties the DOM code can calculate itself.

The engines contain these properties for their own use; otherwise I see the DOM code already knowing these values.

[Manishearth]

We don't need these; the DOM will maintain these values itself I think.

All of the invariants will be upheld by the DOM side as well (aside from invariants that require maintaining an audio param timeline or a graph to validate)

[Manishearth]

again, we don't need getters for these

[ferjm]

I may be missing something, but TBH I don't see much value on duplicating this data on both sides :\

We mostly use this information on the servo-media side. The DOM bindings are mostly a proxy of this data and caching it there will add some extra complexity that IMHO seems unnecessary.

Note that we also need setters for some of these properties.

In general, I am trying to get as much data as possible from servo-media, so the DOM bindings are as thin as possible.

[Manishearth]

I may be missing something, but TBH I don't see much value on duplicating this data on both sides :\

To avoid unnecessary channel traffic. The DOM APIs are sync and should not have to block on the rendering process. There are some cases where this is inevitable but I'd like to minimize it 😄

There's a bunch of DOM-side stuff in the WebAudio APIs that involves calculating errors and such, for which it's best to have this info locally. To me this crate is a lower level abstraction that provides the actual audio processing engines.

This is how Gecko does it as well. The DOM side does all the checks (since it must report errors) and stores a local value, and sends updates to the nodes.