I’ve got a user report of the AudioDeviceManager showing the incorrect sample rate (offset by one position from the correct value in the combobox). I haven’t got an exact repro, but it was observed under the following conditions:
Audio device had non standard sample rates available (i.e. not in the default list)
RME DigiFace USB (which supports 64 kHz and 128 kHz rates as per screen shot)
User frequently changed sample rate using AudioDeviceManager, and
User also changed sample rate from the device’s control panel
In this case the audio device does set the non standard rate and operate correctly
However, at least sometimes the combobox is showing the wrong sample rate
JUCE version was dev branch immediately after this commit (which may ironically be where this can be fixed!).
I was the one who contributed adding 24kHz sample rate for airpod pros - I figure this situation is similar - the need to add 64kHz and 128kHz rates if any device can support them. The bigger problem is that there are hard-coded arrays of sample rates in the code in the first place, but it would be a much bigger refactor to remove them entirely.
There must have been no way for your user to actually use the Digiface at those two unsupported sample rates with anything built using JUCE, and settings them from the OS panel would probably result in undefined behaviour (an off-by-1 or even off-by-2 sample rate would make a lot of sense in this case).
The user (incidentally the device manufacturer) was able to use these sample rates. I’m guessing when they select the sample rate in their own control panel, the device sends a reset, which triggers an update and then the correct sample rate is retrieved by getNominalSampleRate().
Perhaps updateDetailsFromDevice() should check whether the nominal sample rate is not a member of newSampleRates and add it if it isn’t already there.
