We discovered this on a big application at first, but then I managed to reproduce it on a simple JUCE test app, which made me thing it could be a JUCE issue.
In both apps we use AudioDeviceSelectorComponent to manage audio devices. It only happens on Mac M1.
Here are some repro steps:
launch the app while headphones are disconnected; sound will play through the speakers and the devices look like this:
now connect the headphones; notice the output device changed to “external headphones” but, at least in my/our case, the sound keeps coming out of the speakers.
bonus: once an output device is selected (try e.g. with a device that is NOT headphones nor speakers… it could be the ZoomAudioDevice in my case, or whatever you have) try plugging and unplugging the headphones and observe the Output device field: it seems to be flipping between the currently selected device and the previous one… E.g. in my example it could flip between the zoom device and None…
I hope the above gives an idea of what’s happening… Any input will be appreciated, thank you!
this happens for me sometimes with 2019 Macbook Pro 16" Intel - Big Sur - JUCE 7.0.5 master branch
Doesn’t seem to be consistent though, although have the same symptom of not being able to switch to headphones/speakers without first going through another device choice.
Could someone on the JUCE team tell us what’s supposed to be happening here, is this a bug or do we need to find some work around? How does it end up showing the head phones as the current device even though it’s not using it?
OK I think I’ve tracked down the source of the bug. It appears our wrapper around a CoreAudio device effectively caches its index into the array of all the audio devices, so when the combo-box asks for the device at a particular index (after a device has been added or removed) it can get the wrong one. This means it displays a different device, it also means the device names shown and the indexes associated aren’t always correct, hence the selection going wrong too.
I’ll probably need to do some more extensive testing and I’ll try and see if this issue might exist on other platforms too.
I think there is a jassertfalse in AudioDeviceSettingsPanel::resize with your modification
as updateAllControls was called when you were in the widget hierarchy and it’s not the case anymore
