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