I’ve tried reproducing the ASIO problem now. My testing machine has two ASIO device drivers:
- built-in Realtek Audio (speakers)
- Universal Audio Thunderbolt driver (Apollo Solo)
I wasn’t able to reproduce the issue you mentioned, specifically that the audio device callback is no longer called after changing the sample rate. I was still able to play the test sound after changing the sample rate for both devices.
However, I did find a couple of other problems:
- For the Realtek device, switching to the very lowest sample rate (44.1KHz) sometimes caused the test tone to be garbled. Resetting the device seemed to fix the problem.
- For the Universal Audio device, changing the buffer size from the control panel issued a restart request to the device, but then failed to create new buffers afterwards. The problem sounds very similar to the one mentioned here.
For all of these issues, it’s not clear whether the problem is in JUCE or in the device driver.
Do you have any other ASIO device drivers available for testing? Do they all behave in the same way? If not, I’d recommend contacting Focusrite and asking whether they can provide any insights.
I tested a bit in REAPER too, and that was able to play audio successfully when I tried to reconstruct the same scenarios - however, it seems like the configuration flow is substantially different there. As far as I can tell, opening the “Audio device settings” panel closes the audio device completely, and the device is not reopened until the panel is closed. Although we could completely unload and reload the driver on each change (essentially running the same steps as the “Reset Device” button), I don’t think this is a good idea, as it would be very slow. In addition, the ‘state machine’ diagram in the ASIO SDK docs implies that it should be possible for devices to transition between states without requiring the driver to be reloaded each time.