Synchronous encoding/decoding

[w3c]

Synchronous encoding/decoding

[steveanton]

Would it be possible to keep the same API but have a flag which instructs the user agent to run the codec synchronously?

I'm not sure all the requirements for the synchronous API (e.g., whether it's ok to unwind the stack or not), but this approach would at least ensure the encoding/decoding happens in the same task.

[chcunningham]

@anthumchris - I wouldn't expect folks to do much decoding in the AudioWorklet process() loop. Audio rendering needs to meet tight deadlines and be glitch free. The ideal setup would be to do decoding in a worker (async is fine) and send the decoded output to AudioWorklet using a SharedArrayBuffer. See this overview.

[padenot]

Being able to synchronously decode is essential for folding a bit of the packetization latency inside the audio output latency, for a decode-type scenario and lowering the overall end-to-end latency.

[chcunningham]

This also came up in #51. That issue was closed with rationale:

We discussed this in the call w/ audio epxerts. It is true that many are coming from a synchronous API, but they concluded that this was not a requirement for them. We also discussed how our API's under the hood are often async and they stated that they did not desire for us to hide that from them at the JS layer. Please open a new issue for this if I've overlooked anything.

Closing this issue with same reasoning.

[anthumchris]

I think synch audio decoding could be especially important for an AudioWorklet, which would need to use synchronous functions within its process() loop.