1) warning: use of deprecated item 'std::error::Error::description': use the Display impl or to_string()
2) warning: unnecessary `unsafe` block
3) warning: field is never read: `device_id`
Currently we are yet to implement input stream support for CPAL's
webaudio host. Instead of panicking, we should return an
error, None or empty iterator in order to let the user write well
behaved cross-platform apps and notify the user accordingly rather than
crashing.
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?
The `supported_stream_configs` method now returns the range of
configurations that are required to be supported for
`BaseAudioContext.createBuffer()` as mentioned here:
https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/createBuffer
That is, valid stream configurations are now considered to be any
configuration that has:
- 1 <= channel_count <= 32 and
- 8khz <= sample_rate <= 96khz
- sample_format == f32
Closes#410.
Closes#411.
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.