Please see the CHANGELOG diff below for an overview of changes included
in this release.
You can find the full code diff [here](391b32f5b2...master).
Thanks to all who have contributed! CPAL has come a long way thanks to
the combined effort of many different people!
This works by detecting output devices in build_input_stream() and
setting the AUDCLNT_STREAMFLAGS_LOOPBACK flag to enable loopback
recording.
closes#251
To compensate for the removal of `failure`'s application friendly
`failure::Error` trait, this `anyhow` crate has been added as a
dev-dependency for the examples, but is by no means a necessity for
other crates downstream of CPAL.
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.
When using cpal as dependency in other project, it was found that cpal
won't build due to unresolved import of winapi::um::winbase. Added the
feature at line 24 in Cargo.toml.