Public issue https://github.com/mackron/miniaudio/issues/781

Audio Worklets do not work with --closure=1 because the callback used
with emscripten_create_wasm_audio_worklet_processor_async never gets
fired which means miniaudio will never be able to escape from it's busy
wait loop.

Public issue https://github.com/mackron/miniaudio/issues/778

Public issue https://github.com/mackron/miniaudio/issues/779

Unlocked notification fires on emscripten upon successful resume of
audio context attached to a device.  This occurs only once per device
and it happens after the browser has received the input event
necessary to begin playing audio on most webpages.  This is due
to autoplay rules.

It is recommended to wait until this event is fired to start a
'main game loop' on the web.

Public issue https://github.com/mackron/miniaudio/issues/773

Public issue https://github.com/mackron/miniaudio/issues/770

This also fixes a possible crash during initialization due to leaving a
thread running after early termination of the initialization routine.

Public issue https://github.com/mackron/miniaudio/issues/759

occured -> occurred
aquired -> acquired
accomodate -> accommodate
seperate -> separate
etc.

When seeking, the seek does not immediately get applied to the data
source. Instead it is delayed. This results in a situation where the
sound can be seeked, but a small window will exist where querying the
seek point will not be consistent with the previous seek request.

Public issue https://github.com/mackron/miniaudio/issues/750

Public issue https://github.com/mackron/miniaudio/issues/732

https://github.com/mackron/miniaudio/issues/733

If the state miniaudio side of the device does not match the actual
state of the backend side of it, such as when the device is stopped but
the backend doesn't post a notification, attempting to stop the device
might result in a deadlock.

This is a just a quick workaround hack for the moment while a more
robust solution is figured out.

https://github.com/mackron/miniaudio/issues/717