mitchmindtree
commented
6 years ago cc @freesig here's a very rough outline of how I'd approach this. Feel free to post comments or call if you get started on this before we hang and anything is unclear of if you get stuck :+1:
Setup
- Fork and clone CPAL to windows machine and make an
asio_backendbranch - Install ASIO libs.
Generate Rust Bindings
Use rust-bindgen to generate a module of rust bindings to all items/function is ASIO from the ASIO header file(s). The user guide is super handy. There are two options for approaches here - 1. dynamically generate bindings from header at build time using a build.rs script or 2. generate bindings ahead of time using the bindgen CLI. The rust-bindgen folks recommend approach 1. so I reckon we try that. This will mean adding:
- a
build.rsscript to CPAL's cargo.toml directory - an
asio/sys.rsmodule to which the generated bindings will be written (bindgen docs will explain this). - an
asio/mod.rsmodule in which we will write a friendly API for what we need around the raw bindings in thesyssubmodule.
Keep in mind that users should still be able to use cpal on windows without installing ASIO, so we'll have to make sure to fail "gracefully"/silently if ASIO is not available and provide a runtime check for checking whether or not it is available.
CPAL API Implementation
We can now begin implementing the API in CPAL. Tomaka's preference for this seems to be to have an operating-system specific extensions module for each module which will contain all items uniquely availble on that OS. As there are currently none of these modules yet in cpal, we will add them. First, we'll add a pub mod os; to the cpal crate root and a src/os/ directory and a src/os/mod.rs for that module. This is where the platform-specific modules will be placed. Next add a pub mod windows; to the src/os/mod.rs and add the associated src/os/windows.rs file. This is where we will provide the user-friendly windows-specific API so that they can access it via cpal::os::windows::some_function(), etc.
Currently, CPAL is setup so that windows defaults directly to using the wasapi.rs backend (this is basically the WDM backend that Dante won't work properly with). I think what we want to do is create a new backend in the windows module which delegates to either the wasapi.rs backend or the asio.rs backend, depending on whether or not some initialise_asio function or something was called. E.g. a CPAL user who wants to choose asio on windows if it's available might do something like this:
extern crate cpal;
fn main() {
// Only generate code for this block if we're targeting windows.
#[cfg(target_os = "windows")]
{
if cpal::os::windows::is_asio_supported() {
cpal::os::windows::initialise_asio().unwrap();
}
}
// All following cpal function calls and items will now use the `asio` module internally now rather than `wasapi`.
let event_loop = cpal::EventLoop::new();
}So internally, I imagine the windows backend event loop looking something like this:
pub enum EventLoop {
Asio(asio::EventLoop),
Wasapi(wasapi::EventLoop),
}The EventLoop::new() function would construct the correct variant based on whether or not initialise_asio was called or not.
CPAL provides a src/null.rs module as a template for an unimplemented backend, so probably best to copy this into the windows.rs and asio/mod.rs modules to make it easier to get started. From here, it should just be a matter of implementing each of these functions (The ASIO one using the asio/sys.rs module we generated and the windows one by wrapping the asio/mod.rs and wasapi.rs implementations).
freesig
BlueJayLouche
For some reason Dante produces a device for every two channels on Windows' WDM API. This is an issue as the audio server expects to be able to target a single device - targeting multiple devices would require a significant hack and be a special condition only required on windows.
The easiest way forward is probably to add ASIO support to CPAL.
Tomaka has mentioned that he's happy to see ASIO support added and that it should follow a platform-specific extensions API similar to the way winit and glutin do. See his comment here.
cc @freesig maybe we can work out some day after Monday next week (when I get back) to have a sesh and work on this together :+1: