I am looking into a problem with a CoreAudio HAL driver that I maintain. During my debugging, I tried sending a
kAudioDevicePropertyDeviceHasChanged property change on the device in order to force a test application using
juce::AudioDeviceManager to restart its processing.
What I’ve seen is that CoreAudio batches multiple property changes together in one
CoreAudioInternal::deviceListenerProc() callback. Unfortunately,
deviceListenerProc() ignores the
inNumberAddresses argument, and so only checks the first changed selector instead of all of the changed selectors.
This means that depending on the order of properties, the
kAudioDevicePropertyDeviceHasChanged could be missed. I think this is a bug in JUCE, but I am not by any means a CoreAudio expert, so feel free to argue.
I am attaching a patch that changes the code to loop over all the changed properties. I realize that the calls to
deviceRequestedRestart() should probably be pulled out of the loop to be called at most once. The patch is just meant as a starting point to illustrate my point.
Any feedback is welcome!