Seeing as a few large refactors have landed recently, I thought I'd take
this opportunity to do a `cargo fmt` run and standardise on the default
rustfmt settings.
This is a potential alternative to #359. This PR is based on #359.
This approach opts for a dynamically checked sample type approach with
the aim of minimising compile time and binary size.
You can read more discussion on this [here](https://github.com/RustAudio/cpal/pull/359#issuecomment-575931461)
Implemented backends:
- [x] null
- [x] ALSA
- [ ] CoreAudio
- [ ] WASAPI
- [ ] ASIO
- [ ] Emscripten
This is an implementation of the planned changes described in #119.
For a quick overview of how the API has changed, check out the updated
examples.
**TODO:**
- [x] Update API.
- [x] Update examples.
- [ ] Remove `data_type` field from `Format` (see [here](https://github.com/RustAudio/cpal/issues/119#issuecomment-573788380)).
- Update backends:
- [x] null
- [x] ALSA
- [ ] ASIO
- [ ] WASAPI
- [ ] CoreAudio
- [ ] Emscripten
Closes#119Closes#260
Originally this restriction was placed due to uncertainty around the
thread safety of the ASIO API. While the ASIO API itself makes no
thread-safety guarantees that we are aware of, the `asio-sys` high-level
bindings enforce synchronised access to the API and state transitions
via a mutex.
This makes some tweaks to the ASIO backend in order to fix some cases
where races may have occured. This should allow us to remove the `Sync`
bound on the `Device` and `Host` types.
This is in order to ensure consistent restrictions across platforms in a
manner that ensures thread safety across each of the supported
platforms.
Please see added comments in the diff for details on which platforms
impose these restrictions.
- Shares the `Device`'s `driver` and `asio_streams` `Arc`s with the
`Stream`s to ensure they remain valid if the `Host` or `Device` are
dropped early.
- Ensures that a stream's callback is removed upon `Drop`.
For the most part, behaviour should be largely unchanged, however each
individual stream now has its own `set_timeout` callback loop, rather
than using one for processing all streams at once.
Many TODOs remain within the `emscripten` backend. These were left
untouched for the most part in favour of addressing this in a more
web-focused, future PR.
mitchmindtree
Benjamin Saunders
Alex Moon
Sebastian Imlay
Jan Beich
msiglreith
Viktor Lazarev
Tatsuyuki Ishi