You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a tentative API for enumerating audio adapters and creating an audio device with an attached callback. This covers the happy path of a basic capture/playback scenario.
It should be a relatively thin abstraction over both CoreAudio and WASAPI (although it will require some buffering to support both input and output in the same callback). I can probably adapt some old CoreAudio code I wrote for an old project to draft an implementation in the platform layer, and we can work together with Skytrias on a WASAPI backend. We can then figure out more advanced features like device change notifications etc.
Since the API is designed around opaque handles it is straightforward to expose the API to the wasm guest as imported functions, but there are some difficulties to consider:
On native the callback will be called from an audio thread. Currently the wasm interpreter is not multithreaded (and the wasm threading story is not very clear yet).
We could maybe create a second instance of the interpreter working on the same memory, although that's probably messed up if the module needs to touch globals/tables etc.
We could buffer audio an call the wasm callback on the main thread, but that will increase latency and we'll have to figure out how to interleave the timings for audio and graphics.
Ideally, we support calling wasm functions from multiple threads and don't have anything special to do.
We should also avoid calling into the host from inside the callback, so the signature may need to be adjusted to include informations we would otherwise query from the device (e.g. the IO configuration and the user pointer).
The callback will require additional buffer copies.
The text was updated successfully, but these errors were encountered:
Here's a tentative API for enumerating audio adapters and creating an audio device with an attached callback. This covers the happy path of a basic capture/playback scenario.
It should be a relatively thin abstraction over both CoreAudio and WASAPI (although it will require some buffering to support both input and output in the same callback). I can probably adapt some old CoreAudio code I wrote for an old project to draft an implementation in the platform layer, and we can work together with Skytrias on a WASAPI backend. We can then figure out more advanced features like device change notifications etc.
Since the API is designed around opaque handles it is straightforward to expose the API to the wasm guest as imported functions, but there are some difficulties to consider:
On native the callback will be called from an audio thread. Currently the wasm interpreter is not multithreaded (and the wasm threading story is not very clear yet).
We should also avoid calling into the host from inside the callback, so the signature may need to be adjusted to include informations we would otherwise query from the device (e.g. the IO configuration and the user pointer).
The callback will require additional buffer copies.
The text was updated successfully, but these errors were encountered: