fix(coreaudio): crashes from early initialization

[roderickvd]

Configuring the stream after the AudioUnit is initialized breaks the CoreAudio contract and caused crashes on certain drivers.

Fixes #1182

[Copilot]

Pull request overview

Defers CoreAudio AudioUnit initialization until after stream properties/callbacks are configured, avoiding CoreAudio contract violations that can trigger driver crashes (fixes #1182).

Changes:

• macOS: ensure newly created AudioUnits are uninitialized during configuration and only initialized immediately before stream start.
• macOS: query device buffer frame size range via AudioObjectGetPropertyData (device-level) to avoid instantiating/initializing an AudioUnit during device introspection.
• iOS: align RemoteIO setup to configure recording + stream format first, then initialize the AudioUnit.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/host/coreaudio/macos/device.rs	Avoids early AudioUnit initialization and removes AudioUnit dependency from buffer size range queries; initializes only right before starting streams.
src/host/coreaudio/ios/mod.rs	Moves initialization to the end of setup_stream_audio_unit after configuration (including recording mode + stream format).
CHANGELOG.md	Documents the CoreAudio crash fix related to early initialization.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nico-franco-gomez]

I think the changes here would already solve the problem when using the .description() method. Nonetheless, I also experienced some occasional crashes while initializing the audio unit on creating a single output stream, meaning that probably some stale state was still in place when the audio unit was initialized in coreaudio-rs. The PR has already been merged and I expect the publishing of the new version very soon. Therefore, I'd advocate for waiting for that to be available and then avoid the uninitialize steps, because unwanted allocations on the audio devices are still happening in this case. That's the cleaner approach imo, but of course, the decision lies on your side.

[roderickvd]

Sure, if it’ll be released soon then we can wait for that. I’d like to include it in cpal v0.18.

Besides the coreaudio-rs PR, to verify my understanding, does my PR fix it for you completely?

[simlay]

he RustAudio/coreaudio-rs#152 has already been merged and I expect the publishing of the RustAudio/coreaudio-rs#153 very soon.

Sorry. I got distracted earlier (I'm a new father and very tired) and forgot to push the merge button. coreaudio-rs 0.14.2 is published..

[nico-franco-gomez]

I tested the PR right now, and I still could reproduce a crash due to the early initialization inside coreaudio-rs when starting an output stream. Since that's not yet avoided here, it makes sense that it still happens.

But given the new coreaudio-rs version is already available, it would be straight-forward to integrate that in here, right?

Additionally, there's a function called audio_unit_from_device in macos/device.rs. There's the exact same functionality in the public API of coreaudio-rs. I would also suggest to get rid of that function altogether and just import the other one...

[roderickvd]

Thanks. I’ll update soon.

[roderickvd]

Hope this does it - feedback appreciated as I can't reproduce it locally.

[roderickvd]

I'm going to merge this and close #1182. Please re-open that ticket if there are remaining issues.

[nico-franco-gomez]

Ok, I'll have access to my test setup in a couple of days, so I'll notify if I manage to reproduce the crashes again.