Problem
I'm experiencing some stochastic crashes when enumerating my audio devices and getting their names via .description(). Starting an output stream also crashes (I'd say 35% of the time). Apparently, some audio driver is accessing some dead mutex, so I assumed it would be a bug within the audio driver. Nonetheless, going back to v0.16 of CPAL made the crashes almost disappear (it happened only very few times), so I figure something else must be going on.
Sadly, these crashes are making the 0.17.x completely unusable in my case.
Environment
CPAL version 0.17.3.
Mac Mini M2 with MacOS Tahoe 26.4.1.
My main audio interface in this thread is this professional audio device.
This issue appeared much more often in Release Mode than in Debug Mode.
Analysis
After a longer debugging session, I found something that seems to be problematic for my specific driver, but also just looks a bit wrong in general: Audio Units are always being instantiated and initialized directly afterwards. This is triggered inside coreaudio-rs every time. After getting an already initialized audio unit, CPAL is currently setting different things regarding the stream like sample format and such (or just disposing the instance if no stream is to be started). This order does not comply with the standard usage of CoreAudio, because initialization makes more sense only AFTER setting all stream parameters is done (allocations within the audio device happen at initialization and they depend on settings). I believe, this is the root of the problem.
I rewrote that (while also using a dev branch in coreaudio-rs), and all crashes are gone (validated with a significant amount of testing). Additionally, everything else also works just as expected, confirming the idea that audio unit initialization is not necessary for every instance and every usage.
PS: I'm actually not quite sure why the crashes do not happen as often with v0.16, I didn't look much into the differences between the function after I solved it by the strategy already discussed.
Proposal
This should be changed to defer the initialization only before really starting the audio stream AND avoid it altogether if unnecessary (for example when executing .description() because querying device info does not even require such initialization). This requires a PR on the side of coreaudio-rs in order to change the API. It would also be a much cleaner approach in my opinion.
I'm aware that it's probably a hardware bug, but I think it's still an improvement for the crate.
Pre-requirement
As already mentioned, this requires new functionality from coreaudio-rs. This is the PR. Once that's merged, I'll gladly proceed with a PR on this side, while also updating to the latest version of coreaudio-rs, of course.
Problem
I'm experiencing some stochastic crashes when enumerating my audio devices and getting their names via
.description(). Starting an output stream also crashes (I'd say 35% of the time). Apparently, some audio driver is accessing some dead mutex, so I assumed it would be a bug within the audio driver. Nonetheless, going back to v0.16 of CPAL made the crashes almost disappear (it happened only very few times), so I figure something else must be going on.Sadly, these crashes are making the 0.17.x completely unusable in my case.
Environment
CPAL version 0.17.3.
Mac Mini M2 with MacOS Tahoe 26.4.1.
My main audio interface in this thread is this professional audio device.
This issue appeared much more often in Release Mode than in Debug Mode.
Analysis
After a longer debugging session, I found something that seems to be problematic for my specific driver, but also just looks a bit wrong in general: Audio Units are always being instantiated and initialized directly afterwards. This is triggered inside
coreaudio-rsevery time. After getting an already initialized audio unit, CPAL is currently setting different things regarding the stream like sample format and such (or just disposing the instance if no stream is to be started). This order does not comply with the standard usage of CoreAudio, because initialization makes more sense only AFTER setting all stream parameters is done (allocations within the audio device happen at initialization and they depend on settings). I believe, this is the root of the problem.I rewrote that (while also using a dev branch in
coreaudio-rs), and all crashes are gone (validated with a significant amount of testing). Additionally, everything else also works just as expected, confirming the idea that audio unit initialization is not necessary for every instance and every usage.PS: I'm actually not quite sure why the crashes do not happen as often with v0.16, I didn't look much into the differences between the function after I solved it by the strategy already discussed.
Proposal
This should be changed to defer the initialization only before really starting the audio stream AND avoid it altogether if unnecessary (for example when executing
.description()because querying device info does not even require such initialization). This requires a PR on the side ofcoreaudio-rsin order to change the API. It would also be a much cleaner approach in my opinion.I'm aware that it's probably a hardware bug, but I think it's still an improvement for the crate.
Pre-requirement
As already mentioned, this requires new functionality from
coreaudio-rs. This is the PR. Once that's merged, I'll gladly proceed with a PR on this side, while also updating to the latest version ofcoreaudio-rs, of course.