Difficult to understand documentation regarding wasm

[Moxinilian]

The main page of the documentation states

Note: Creating and running a stream will not block the thread. On modern platforms, the given callback is called by a dedicated, high-priority thread responsible for delivering audio data to the system's audio device in a timely manner. On older platforms that only provide a blocking API (e.g. ALSA), CPAL will create a thread in order to consistently provide non-blocking behaviour (currently this is a thread per stream, but this may change to use a single thread for all streams). If this is an issue for your platform or design, please share your issue and use-case with the CPAL team on the github issue tracker for consideration.

However, this is difficult to understand in the context of wasm. In fact, I believe in the WebAudio host it is not the case: the processing seems to happen in a timeout event which as far as I know is not a dedicated thread. Perhaps adding some clarification about wasm would help?

[mitchmindtree]

Thanks for the issue!

cc @dpeckett as they did the lion's share of the work in landing the webaudio host - any advice or thoughts on this would be greatly appreciated!

@Moxinilian I did notice the timeouts as well - my assumption was that these worked by "scheduling" the function to get called after the amount of time has passed, freeing the process to do work in the meantime, but I'm certainly not familiar enough with WASM or the webaudio backend to be sure. Either way, I think you're right that it would be nice to document this behaviour too. A PR adding a note about the WebAudio behaviour (once we get to the bottom of it) would be very welcome.