This implements the changes described at #370.
This commit implements only the `null` and `alsa` backends - the rest
will be implemented in follow-up commits.
Closes#370.
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 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.
This works by detecting output devices in build_input_stream() and
setting the AUDCLNT_STREAMFLAGS_LOOPBACK flag to enable loopback
recording.
closes#251
Currently CPAL only really uses `failure` for its `derive` capabilities
and the ability to easily generate implementations for `Display`. That
said there are a few issues with using the `failure` crate:
- `failure` does not provie a `std::error::Error` implementation without
first converting error types into `failure::Error`.
- It leaks significantly into the public API and expects downstream
users to also depend on `failure` and the non-std `Fail` trait for
their own error handling.
- Solved problems such as downcasting of causal errors which have since
been addressed in `std`.
- Provides application-friendly `Fail` trait and `failure::Error` type,
not particularly useful to libraries like CPAL.
The [`thiserror` crate](https://github.com/dtolnay/thiserror) is better
targeted towards libraries, does not leak into the public API while
providing easy generation of `Display`, `From` and `std::error::Error`
implementations including proper handling of the newish
`std::error::Error::source` method.
The hardcoded errno was replaced by a constant, and `snd_pcm_prepare` was replaced by `snd_pcm_recover` per best practice (the underlying implementation seems same for now, though).
This existed prior to the introduction of the `Host` API, but was lost
in translation. This re-adds the bounds so that downstream code does not
suddenly break due to a lacking `Hash` implementation in the next
CPAL version.
Most of this is an attempt at improving readability and modularity of
the asio-sys crate while attempting to review it for correctness. Still
unsure why glitching is occasionally occuring on output, but recorded
input sounds perfectly clean.
ASIO has a limitation where it only supports loading a single audio
driver at a time. This fixes a common error where CPAL users would
request both the default input device and output device in separate
`load_driver` calls. Now, `load_driver` will return another handle to
the existing driver if the existing driver has the same name.
Instead, we use some traits and generics in an attempt to retain a
little readability. See the remaining TODOs in this section for required
future work.