Very intermittent Core Audio errors

When I leave my program running overnight in debug, when I come back it has crashed with a Core Audio error.

Juce nicely jasserts in debug but the stack (below) and other log information seem to show that Core Audio just decided to return a random error at some point in the middle of the night while nothing else was happening… the very illuminating CoreAudio error: 277254 - 216f626a

Searching for Core Audio errors in general or this one in particular has been singularly unenlightening - and this isn’t a Mac forum!

My question is rather, is recovery possible as far as Juce is concerned? In a non-debug build, it looks to me as if the Juce code should just continue on. Should I simply pretend nothing happened, and if the user isn’t getting sound, I’ll rely on them to curse a little and restart the program?

I don’t actually know if the program keeps working after hitting this core audio error, I haven’t run an optimized build overnight (I haven’t run anything systematically overnight, I just forget to shut it off :-D)

#0 0x92616dca in Debugger
#1 0x0033fb4e in juce::logAnyErrors_CoreAudio at juce_amalgamated.cpp:277089
#2 0x004e3b1e in juce::CoreAudioInternal::updateDetailsFromDevice at juce_amalgamated.cpp:277254
#3 0x004e4bb6 in juce::CoreAudioInternal::timerCallback at juce_amalgamated.cpp:277737
#4 0x004399f0 in juce::InternalTimerThread::callTimers at juce_amalgamated.cpp:39296
#5 0x00439b4b in juce::InternalTimerThread::handleMessage at juce_amalgamated.cpp:39312
#6 0x0025ec65 in juce::MessageManager::deliverMessage at juce_amalgamated.cpp:38890
#7 0x00499cc7 in juce::MessageQueue::deliverNextMessage at juce_amalgamated.cpp:262984
#8 0x00499d56 in juce::MessageQueue::runLoopCallback at juce_amalgamated.cpp:262991
#9 0x00499d9b in juce::MessageQueue::runLoopSourceCallback at juce_amalgamated.cpp:263000

It looks like a device changed its state for some reason while it was running - maybe the driver crashed or timed-out or some other unexpected thing happened. So I guess that whether the app would have carried on running depends on what actually happened to the driver. As you can see in the timerCallback() method on the stack, the juce device has to stop if the sample rate or buffer size change, but could carry on if they’re still ok.