ASIO: open control panel

[Sin-tel]

Just putting this here for now so people know it is at least possible.

Will have to think about a proper API if we want to include this. (extension traits?)
I would also be fine having this only exposed in asio-sys for now, but you'd need to expose driver internals if you want to use it from cpal.

Also, I had to modify the build script to get rid of linker errors, not sure what's up with that.

[roderickvd]

Hey! I think the asio-sys part is worth having regardless of the cpal API discussion. While I believe the ASIO control panels are blocking modals, it seems that PortAudio and JUCE also expose them.

For the build script changes: the linker errors make sense - ASIOControlPanel() uses Windows registry APIs (Advapi32) and UI functions (User32). Just noting that you have user32 on line 66 and User32 on line 68 - they're the same lib on Windows (case-insensitive) so it works, just redundant.

Re: the cpal API, I agree we should use extension traits rather than exposing this through as_inner() downcasting. Here's what I'm thinking:

// In src/platform/asio.rs or similar
#[cfg(all(target_os = "windows", feature = "asio"))]
pub trait AsioDeviceExt {
    fn asio_open_control_panel(&self) -> Result<(), BackendSpecificError>;
}

impl AsioDeviceExt for Device {
    fn asio_open_control_panel(&self) -> Result<(), BackendSpecificError> {
        if let DeviceInner::Asio(ref d) = self.as_inner() {
            d.open_control_panel()
        } else {
            // or maybe introduce a new error variant
            Err(BackendSpecificError {
                description: "Not an ASIO device".to_string(),
            })
        }
    }
}

Usage would be like:

use cpal::platform::asio::AsioDeviceExt;

let device = host.default_output_device()?;
device.asio_open_control_panel()?;

This keeps the main Device trait platform-agnostic while allowing opt-in access to host-specific features. We could do similar for WASAPI exclusive mode, ALSA period counts, etc.

[roderickvd]

Had the above extension traits in mind for v0.18 by the way, not v0.17.

[Sin-tel]

Cool, trying out the extension trait now. It seems pretty nice! How I did it right now still has the problem with docs not generating though.

[roderickvd]

Some considerations inline. Let's pay particular attention to getting the extension traits right. When we start adding them, it'd be highly desirable to keep them consistent and stable for the other hosts and time to come.

Also don't forget about a changelog entry.

[roderickvd]

What do you think about making this an example in asio-sys/examples instead?

[Sin-tel]

The example is a bit useless I think, was kind of intended to just show off that it works at all. With the extension trait it's not really necessary anymore.

[roderickvd]

@Sin-tel how's your extension traits experiment coming along? Not to haste - just checking in.
This should become the template for extension traits in other hosts as well.

[Sin-tel]

Got distracted by other things. Mostly done now!

Any idea why windows-crate-v0.61.3 is failing?

EDIT: Seems like windows runners are randomly failing, I'm blaming github since it's all working fine for me locally.