On my system at least, I reliably get a CoreAudio error when I simply turn my interface off, which results in a jassert and program halting in a debug build, and just a log file entry in a release build.
I assume when I start wider testing I’ll find all sorts of ways to generate CoreAudio errors.
I’d much rather get a chance to handle such errors myself (probably bringing up a dialog saying, “The program’s lost connection with your audio interface, perhaps because it was turned off or disconnected”).
Ok… Is there a particular place in the code that’s asserting, or is it just whenever a CoreAudio call is made after the device was removed?
Oh, sorry, should have been clearer.
See juce_mac_CoreAudio.cpp, line 52 (or so, I haven’t updated in a few weeks), where the assert goes off.
Really, what I’d like is to be able to drop my own function into the place of logAnyErrors_CoreAudio
Hmm, the logging in there was really just for debugging - I guess the only clean way to expose a callback function would be to add a virtual method to the AudioIODeviceCallback, which could be possible…
For error handling, you could simply let us set a function pointer as a one-time call in main() before CoreAudio even started up…
but an error callback would be really nifty, I can imagine you’d use that in Windows-world sooner or later, too!