Detecting changes in core audio configuration after external change

I have an issue when another application opens the output audio device I have opened in my application, with a sample rate that my current configuration does not support:

My application opens:

  • Mac Pro Speakers as output
  • Dante Via Stereo ( an input device that only supports 48Khz sample rate)
  • Buffer size 512, Sample rate 48 Khz.

Another (Juce) application then opens:

  • Mac Pro Speakers as output
  • No input device
  • buffer size 512, Sample rate 41.1 Khz.

My custom audio callback sees the current audio device being closed, but not reopened. The audio device manager cannot reopen the current configuration since the output device has changed to 44.1 KHz and the selected input does not support that rate.

I start a timer and when the callback does not get reopened, I know something fishy is going on.
When the timer callback fires, I poll the current audio device and get it’s current settings and supported samplerates / buffer sizes.
They don’t reflect the change to 44.1 Khz and still report only the 48 Khz as supported (and active) rate.

However, If I dig a bit with the debugger, I can see one of the two active Core Audio “internal”
objects has 44.1 Khz as its sample rate (the output), while the other is still at 48Khz. It seems it’s not easy to retrieve that information withouth heavy modification of the (core) audio device code.

I would like to be able to detect that the active audio device configuration has 0 shared sample rates between its selected input and output devices. From there I could try a different configuration (clear out the input device) that would allow me to reopen the output.

Is there some way of forcing the audio device to update its details from the outside?