This adds the `wasm-beep` example @ishitatsuyuki put together for
testing webaudio support. The example helped me to better understand how
to use the webaudio host and provided an easy way to test it, I'm sure
other contributors/users might benefit in the same way.
I guess in the future it would be nice if we could have some way of
sharing the same code between wasm-target examples and native target
examples. Still, I think it's beneficial to include this wasm-beep
example in the meantime to have at least some kind of demonstration of
how to use cpal with wasm.
Are you happy for this to be added as is @ishitatsuyuki?
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
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.
This is a draft implementation of #294. I'll leave this open for
feedback and potentially better trait naming suggestions or better
solutions in general!
cc @ishitatsuyuki
This is an implementation of the API described at #204. Please see that
issue for more details on the motivation.
-----
A **Host** provides access to the available audio devices on the system.
Some platforms have more than one host available, e.g.
wasapi/asio/dsound on windows, alsa/pulse/jack on linux and so on. As a
result, some audio devices are only available on certain hosts, while
others are only available on other hosts. Every platform supported by
CPAL has at least one **DefaultHost** that is guaranteed to be available
(alsa, wasapi and coreaudio). Currently, the default hosts are the only
hosts supported by CPAL, however this will change as of landing #221 (cc
@freesig). These changes should also accommodate support for other hosts
such as jack #250 (cc @derekdreery) and pulseaudio (cc @knappador) #259.
This introduces a suite of traits allowing for both compile time and
runtime dispatch of different hosts and their uniquely associated device
and event loop types.
A new private **host** module has been added containing the individual
host implementations, each in their own submodule gated to the platforms
on which they are available.
A new **platform** module has been added containing platform-specific
items, including a dynamically dispatched host type that allows for
easily switching between hosts at runtime.
The **ALL_HOSTS** slice contains a **HostId** for each host supported on
the current platform. The **available_hosts** function produces a
**HostId** for each host that is currently *available* on the platform.
The **host_from_id** function allows for initialising a host from its
associated ID, failing with a **HostUnavailable** error. The
**default_host** function returns the default host and should never
fail.
Please see the examples for a demonstration of the change in usage. For
the most part, things look the same at the surface level, however the
role of device enumeration and creating the event loop have been moved
from global functions to host methods. The enumerate.rs example has been
updated to enumerate all devices for each host, not just the default.
**TODO**
- [x] Add the new **Host** API
- [x] Update examples for the new API.
- [x] ALSA host
- [ ] WASAPI host
- [ ] CoreAudio host
- [ ] Emscripten host **Follow-up PR**
- [ ] ASIO host #221
cc @ishitatsuyuki more to review for you if you're interested, but it
might be easier after #288 lands and this gets rebased.
This allows for properly handling potential failure on macOS. We should
also consider propagating the mutex/channel poison errors through these
new types, especially considering the potential removal of the event
loop in favour of switching over to high-priority audio threads on
windows and linux.
See the documentation for both new errors for details.
The new `DevicesError` has been added to allow for returning errors when
enumerating devices. This has allowed to remove multiple potential
`panic!`s in each of the alsa, coreaudio and wasapi backends.
* Update to a more general Device and Stream API
This update prepares for adding input stream support by removing the
`Endpoint` type (which only supports output streams) in favour of a more
general `Device` type which may support any number of input or output
streams. Previously discussed at #117.
The name `Voice` has been replaced with the more ubiquitous name
`Stream`. See #118 for justification.
Also introduces a new `StreamData` which is now passed to the
`EventLoop::run` callback rather than the `UnknownTypeBuffer`.
`StreamData` allows for passing either `Input` data to be read, or
`Output` data to be written.
The `beep.rs` example has been updated for the API changes.
None of the backends have been updated for this API change yet. Backends
will be updated in the following commits.
Closes#117.
Closes#118.
* Update ALSA backend for new `Device` and `Stream` API.
* Update wasapi backend for new `Device` and `Stream` API.
* Update enumerate.rs example for new `Device` and `Stream` API.
* Update coreaudio backend for new `Device` and `Stream` API.
* Fix lib doc tests for Device and Stream API update
* Update emscripten backend for new `Device` and `Stream` API.
* Update null backend for new `Device` and `Stream` API.
* Merge match exprs in beep.rs example
* Add Input variant along with UnknownTypeInputBuffer and InputBuffer
UnknownTypeBuffer and Buffer have been renamed to
UnknownTypeOutputBuffer and OutputBuffer respectively.
No backends have yet been updated for this name change or the addition
of the InputBuffer.
* Update null backend for introduction of InputBuffer
* Update emscripten backend for introduction of InputBuffer
* Make InputBuffer inner field an option to call finish in drop
* Update alsa backend for introduction of InputBuffer
* Update wasapi backend for introduction of InputBuffer
* Update coreaudio backend for introduction of InputBuffer
* Update enumerate.rs example to provide more detail about devices
The enumerate.rs example now also displays:
- Supported input stream formats.
- Default input stream format.
- Default output stream format.
This should also be useful for testing the progress of #201.
* Add `record_wav.rs` example for demonstrating input streams
Records a ~3 second WAV file to `$CARGO_MANIFEST_DIR/recorded.wav` using
the default input device and default input format.
Uses hound 3.0 to create and write to the WAV file.
This should also be useful for testing the input stream implementations
for each different cpal backend.
* Implement input stream support for coreaudio backend
This implements the following for the coreaudio backend:
- Device::supported_input_formats
- Device::default_input_format
- Device::default_output_format
- EventLoop::build_input_stream
The `enumerate.rs` and `record_wav.rs` examples now work successfully on
macos.
* Add `SupportedFormat::cmp_default_heuristics` method
This adds a comparison function which compares two `SupportedFormat`s in
terms of their priority of use as a default stream format.
Some backends (such as ALSA) do not provide a default stream format for
their audio devices. In these cases, CPAL attempts to decide on a
reasonable default format for the user. To do this we use the "greatest"
of all supported stream formats when compared with this method.
* Implement input stream support for ALSA backend
This implements the following for the ALSA backend:
- Device::supported_input_formats
- Device::default_input_format
- Device::default_output_format
- EventLoop::build_input_stream
Note that ALSA itself does not give default stream formats for its
devices. Thus the newly added `SupportedFormat::cmp_default_heuristics`
method is used to determine the most suitable, supported stream format
to use as the default.
The `enumerate.rs` and `record_wav.rs` examples now work successfully on
my linux machine.
* Implement input stream support for wasapi backend
This implements the following for the wasapi backend:
- Device::supported_input_formats
- Device::default_input_format
- Device::default_output_format
- EventLoop::build_input_stream
Note that wasapi does not enumerate supported input/output stream
formats for its devices. Instead, we query the `IsFormatSupported`
method for supported formats ourselves.
* Fix some warnings in the alsa backend
* Update CHANGELOG for introduction of input streams and related items
* Update README to show latest features supported by CPAL
* Simplify beep example using Device::default_output_format
* Remove old commented code from wasapi/stream.rs
* Rename SamplesRate to SampleRate and samples_rate to sample_rate
* Rename ChannelsCount to ChannelCount
* Update CHANGELOG for SamplesRate and ChannelsCount renaming
* Remove ChannelPosition API
This removes the ChannelPosition API from the lib root and updates the
ALSA backend and examples accordingly. The other backends have not yet
been updated.
Related discussion at #187.
* Update windows backend to removal of ChannelPosition API
The windows backend now assumes the channel position order is equal to
the channel position mask order. E.g. channel 0 will always be front
left, channel 1 will always be front right, etc.
Compiled and ran both examples successfully.
* Update coreaudio backend to removal of ChannelPosition API
Compiled and ran both examples successfully.
* Update emscriptem backend for removal of ChannelPosition API
* Update CHANGELOG for ChannelPosition removal
Based on #195.
Also implements proper handling of the given `Endpoint` in the
macos implementation of the `build_voice` method.
Updates to the latest coreaudio-sys and coreaudio-rs which include the
additional necessary frameworks.
Also adds a line that prints the name of the default device in the
`enumeration.rs` example.
Updates the CHANGELOG for this PR.
Closes#194.
Related to #180.
Related external issues:
- RustAudio/coreaudio-sys#4
- RustAudio/coreaudio-rs#57
* Rework the API to not use futures anymore
* Add some comments
* Update the MacOS backend
* Restore the null implementation
* Add an emscripten backend
* Remove erroneously added feature
* Fix to_f32 formula
* [WIP] Alsa backend
* Alsa backend compiling
* Working ALSA backend
* Fix tests
* Move WASAPI endpoint to endpoint module
* Fix WASAPI warnings
* Rework the WASAPI backend
* Check overflows for voice ID
* Add comments and minor fixes to WASAPI backend
* Add a changelog
snd_pcm_pause could have been used but not all hardware implement it, so
I propose not to use it.
In this implementation:
there are two kind of scheduling: wait for resume signal and wait for
pcm to be available
if the stream is paused then it return notready and wait for resume
the event loop is different as it manages descriptors corresponding to
voices according to the nature of the scheduling.
there is still a FIXME: in voice.play the is signal is send even if
the event loop wasn't waiting for resume.
It doesn't seem to create any issue. But it happens when you write
voice.pause();voice.play();
dependabot[bot]
mitchmindtree
Tatsuyuki Ishi
est31
Benjamin Saunders
Mitchell Hentges
Mohanson
tomaka
jansol
thiolliere