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.
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?
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
Damian Peckett
JoshuaBatty
Thomas Havlik
Richard Dodd
Alex Moon
est31
Brian Schwind
Dan
est31