Channel names: CoreAudio and ASIO by nico-franco-gomez · Pull Request #1254 · RustAudio/cpal

nico-franco-gomez · 2026-06-25T12:03:50Z

This PR refers to this issue.

I implemented a version of this to showcase how I imagined it. When I wrote the issue, I hadn't realized that the error convention had changed from 0.16 to 0.17. This PR adheres to the current error convention.

roderickvd · 2026-07-21T21:38:58Z

Sorry for the late reply on this one.

I think this is a worthwhile addition as a trait method. You could add a default implementation to the trait method to prevent the duplication at each backend that doesn't support it.

Before we go further, could you rebase this onto the develop branch? We're staging upcoming feature work there rather than master right now. I intend to promote it to master for a v0.19 release after we push out a v0.18.2 bug fix release.

Happy to take a deeper look once it's rebased!

nico-franco-gomez · 2026-07-23T19:56:51Z

No problem regarding the delay.

I rebased and implemented the comments while trying to keep a compact, readable git history. Not sure why that specific Linux check is failing, though...

roderickvd

Thanks again, please find my first review attached.

I've promoted develop to master, so please rebase on master where we'll continue the 0.19.0 work. This should be easier to the last rebase, as it's just continuing the develop branch under a new name, basically.

roderickvd · 2026-08-16T20:11:11Z

+
+fn get_channel_name_for_device(
+    device_id: AudioDeviceID,
+    channel_index: u16,


Querying an out-of-range channel_index will return a BackendError I think, when InvalidInput would be preferred.

Good point, I introduced a new check for that in here

roderickvd · 2026-08-16T20:12:43Z

                        .collect();

+                    let input_channel_names: Box<[String]> = (0..channels.ins)
+                        .map(|ch| driver.channel_name(ch, true).unwrap_or_default())


Question: rather than defaulting to an empty string, what if we returned something recognizable like "Channel {ch}"?

I introduced these default names, but I thought about the case where the driver leaves that unfilled knowingly, so I'd argue that for the low-level crate, the caller should decide what the default name in that case should be. What do you think?

roderickvd · 2026-08-16T20:15:18Z

+    pub fn channel_name(&self, channel: i32, is_input: bool) -> Result<String, AsioError> {
+        let _guard = self.inner.lock_state();
+        let info = asio_channel_info(channel, is_input)?;
+        Ok(driver_name_to_utf8(&info.name).into_owned())


I think this was already the case elsewhere with other names, but it's occurring to me that this will UB if there's ever a driver that doesn't NUL-terminate.

roderickvd · 2026-08-16T20:16:31Z

                        .filter(|&r| driver.can_sample_rate(r.into()).unwrap_or(false))
                        .collect();

+                    let input_channel_names: Box<[String]> = (0..channels.ins)


We may want to check that the number of channels is greater than (or equal to) 0. I remember that ASIO often returns an i32 and we wouldn't want a negative value overflowing this.

roderickvd · 2026-08-16T20:17:36Z

+    channel_index: u16,
+    input: bool,
+) -> Result<String, Error> {
+    let mut channel_name: *mut CFString = std::ptr::null_mut();


As this CFString stuff is getting used more often, we could consider having a helper for it.

roderickvd · 2026-08-16T20:19:25Z

    }
+
+    fn get_channel_name(&self, channel_index: u16, input: bool) -> Result<String, Error> {
+        if input && !self.supports_input() {


supports_input/output aren't free, so if it's just to detail the error message then maybe we should just use the input argument but not re-query the device (or cache it, but that may be scope creep).

True. Since there's now the channel_index check, the error message is descriptive enough so that these checks are redundant.

roderickvd · 2026-08-16T20:21:19Z

    input_sample_format: Option<SampleFormat>,
    output_sample_format: Option<SampleFormat>,
    supported_sample_rates: Box<[SampleRate]>,
+    input_channel_names: Box<[String]>,


CoreAudio doesn't seem to cache this. What's the preferred approach? Lazily like CoreAudio or caching it during enumeration here?

I honestly prefer to do it lazily, my rationale is the following: the operation for CoreAudio is low-cost and can be done on demand. Since most users won't need it, I prefer for a lower-level crate to avoid such implicit operations. The operation for ASIO on the other hand is not low-cost because it requires loading the driver and potentially unloading the previous one. It's also risky if there's a callback running in another thread. That's why I find it reasonable to cache it there, but here, I would argue it's unnecessary.

roderickvd · 2026-08-16T20:24:30Z

@@ -943,6 +943,18 @@ impl Driver {
        let mut dcb = DRIVER_EVENT_CALLBACKS.lock().unwrap();
        dcb.retain(|&(id, _)| id != rem_id);


cpal doesn't use get_ for accessors.

Here you're referring to the get_channel_name method, right?

roderickvd · 2026-08-16T20:25:57Z

+    /// (`false`) direction.
+    ///
+    /// The driver must already be loaded (i.e. this `Driver` instance must be alive).
+    pub fn channel_name(&self, channel: i32, is_input: bool) -> Result<String, AsioError> {


Not sure about the input: bool or is_input: bool arguments in public functions. In the rest of cpal, that's split between supports_input/output, default_input/output_config, etc. That's more readable than channel_name(1, true) - what argument isn't self-explanatory.

before rewriting this completely, what do you think could be a better API? Maybe input_channel_name(1) and output_channel_name(1) ?

doc # Conflicts: # src/platform/mod.rs # src/traits.rs introduce default implementation a update example device

# Conflicts: # src/host/asio/device.rs

simplify unsafe structure

roderickvd added the enhancement label Jul 21, 2026

nico-franco-gomez force-pushed the feature/channel-names-coreaudio-asio branch from c27ac0a to f2ba085 Compare July 23, 2026 17:55

nico-franco-gomez changed the base branch from master to develop July 23, 2026 17:55

nico-franco-gomez force-pushed the feature/channel-names-coreaudio-asio branch from f2ba085 to 8374eff Compare July 23, 2026 17:57

This was referenced Aug 14, 2026

Feature: Adding support for retrieval of ASIO channel names - 0.3.1 #1303

Open

Channel selection API #1301

Open

roderickvd requested changes Aug 16, 2026

View reviewed changes

nico-franco-gomez added 10 commits August 27, 2026 02:17

introduce new function to trait

a18f2ba

doc # Conflicts: # src/platform/mod.rs # src/traits.rs introduce default implementation a update example device

feature(asio-sys): make channel name available

c1db839

feature(asio): implement channel name with cache on enumeration

bb3a90e

# Conflicts: # src/host/asio/device.rs

feature(coreaudio): implement channel names

4fac942

simplify unsafe structure

fix(coreaudio): check channel index

112515f

(asio): use default channel names if empty

e7a2442

fix(asio): avoid reading past vector length

2fb7494

fix(asio): avoid negative channel number by returning error

3a23e25

(coreaudio): create CFString helper and replace usages

f79cf46

(coreaudio): remove querying device, channel check covers it

6bd1356

nico-franco-gomez force-pushed the feature/channel-names-coreaudio-asio branch from 8374eff to 6bd1356 Compare August 27, 2026 00:48

nico-franco-gomez changed the base branch from develop to master August 27, 2026 00:48

nico-franco-gomez added 4 commits August 27, 2026 06:22

update documentation

73567ec

(coreaudio): correct clippy issue macos

c454a83

(asio): solve some issues

786b3ef

(asio): correction

178d099

		@@ -943,6 +943,18 @@ impl Driver {
		let mut dcb = DRIVER_EVENT_CALLBACKS.lock().unwrap();
		dcb.retain(\|&(id, _)\| id != rem_id);

Uh oh!

Conversation

nico-franco-gomez commented Jun 25, 2026

Uh oh!

roderickvd commented Jul 21, 2026

Uh oh!

nico-franco-gomez commented Jul 23, 2026

Uh oh!

roderickvd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nico-franco-gomez Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nico-franco-gomez Aug 28, 2026 •

edited

Loading