Minor Mac bug? : when initialising AudioDeviceManager twice

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 :slight_smile:

Please can you check whether you see the same issue with the develop branch? 6.1.5 is a bit old, so the issue may already have been fixed. In particular, I think this commit may resolve the problem:

Hi reuk,

I just tested with latest develop.
But I am still seeing the same problem.

In case it matters:
I am on an Intel MacBook Pro and using the “MacBook Pro Speakers” device.