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 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?
This should give the user a higher confidence that, if they have a
`SupportedStreamConfig` format type that it is actually supported.
Also updates the `raw` stream builder methods to take a `StreamConfig`
and `SampleFormat` as separate arguments for flexibility.
**Backends Updated**
- [x] null
- [x] alsa
- [ ] emscripten
- [ ] coreaudio
- [ ] wasapi
- [ ] asio
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.
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 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.
Now runs the beep and enumerate examples nicely! Time to do a proper
code review of the ASIO stuff and see how to best take advantage of the
new `Host` API.
mitchmindtree
Damian Peckett
Benjamin Saunders
Jan Beich
msiglreith
Tatsuyuki Ishi
Viktor Lazarev
Tom Gowan
Tom Gowan