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.
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?
Rob Watson
Konstantin Baltruschat
mitchmindtree
dependabot[bot]
ely-uf
Tatsuyuki Ishi
Damian Peckett
JoshuaBatty
Thomas Havlik
Richard Dodd