I am running a JUCE standalone app on MacOS 11.6.2 with JUCE 6.1.5
I tried to find out, why the AudioDeviceSelectorComponent did not automatically updated the sample rate, when I change it in a different application, such as Logic Pro. I am talking about a “live” update here. I.e. while the AudioDeviceSelectorComponent is showing. It still updates correctly, if I close the AudioDeviceSelectorComponent and re-open it.
It turns out: my error was that I did initialise the AudioDeviceManager twice.
I do agree that its a bit unnecessary to initialise it twice. But I wonder if it may be a JUCE bug, that initialising it twice prevents the sample rate changes to live update in the AudioDeviceSelectorComponent?
So the problem is the following:
When you initialise the AudioeDeviceManager, a call to AudioDeviceManager::stopDevice() is made. The first time you initialise the device, currentAudioDevice is a nullptr. That is good, because then no call to CoreAudioIODevice::stopDevice() is made. But the second time, currentAudioDevice is not null. Therefore CoreAudioIODevice::stopDevice() is called. The problem is that CoreAudioIODevice::stopDevice() sets restartDevice = false. That in turn causes CoreAudioInternal::timerCallback() to not call owner.restart(). Which in turn prevents the live update of the AudioDeviceSelectorComponent.
As far as I can see, this is just resulting in an UI bug. I.e. the live update of the sample rate in the AudioDeviceSelectorComponent. So it’s more of a minor bug. But I thought I mention it anyways 