This adds the `wasm-beep` example @ishitatsuyuki put together for
testing webaudio support. The example helped me to better understand how
to use the webaudio host and provided an easy way to test it, I'm sure
other contributors/users might benefit in the same way.
I guess in the future it would be nice if we could have some way of
sharing the same code between wasm-target examples and native target
examples. Still, I think it's beneficial to include this wasm-beep
example in the meantime to have at least some kind of demonstration of
how to use cpal with wasm.
Are you happy for this to be added as is @ishitatsuyuki?
This rebases #372, addressing the recent changes introduced by #397, #395, and #371 in the process.
TODO:
- [ ] Complete implementation of `callback` and `playback` timestamps in the output stream callback.
I think this is mostly complete, however there are two major TODOs:
- There seems to be a bug where timestamps are not reported when the
target device is `pulse`. This causes a `panic!` as the trigger
timestamp should always precede the timestamp when retrieved while the
stream is running.
- We need to specify the timestamp type as MONOTONIC_RAW, however the
`alsa` and `alsa-sys` crates do not yet expose the necessary
`set_tstamp_type` function.
Using an unsigned representation was problematic as some platforms
provide no exact "capture" instant. As a result, we need to calculate
the instant of capture by subtracting the buffer duration from the
callback duration. In some cases this would occasionally cause the
unsigned representation to underflow unnecessarily.
I began on an implementation of the timestamp API described in #363 but
quickly realised that it might be best to land the API for providing
extra information to the user's callback first.
This PR adds two new types: `InputCallbackInfo` and `OutputCallbackInfo`.
These types are delivered to the user's data callback as a new, second
argument.
While these types are currently empty, the intention is for these types
to provide information relevant to the current request for or delivery
of data. This includes:
- Timestamp information #363.
- Flags related to the state of the stream (e.g buffer
underflow/overflow).
In order to maintain flexibility to avoid breaking things, I figure we
can keep the fields of these types private and provide methods for
retrieving this info.
@Ralith, @ishitatsuyuki does this seem OK to you?
The `alsa-sys` crate repository has lived [here][1] for quite a while.
This commit removes the unnecessary step from the CI workflow now that
alsa-sys has finally been removed as of #386.
[1]: https://github.com/diwic/alsa-sys
mitchmindtree
Tatsuyuki Ishi
Damian Peckett
JoshuaBatty
Thomas Havlik
Richard Dodd
Alex Moon
est31
Brian Schwind
Dan
est31