AudioDeviceManager::initialise() change breakes existing code

This commit broke our AudioDevice handling:

AudioDeviceManager: Always try to pick an initial device type that has some connected devices
34bda5d75b60e6a8b1f21bd1cf07bc4ee69c60ae

The cause is the newly added call to AudioDeviceManager::pickCurrentDeviceTypeWithDevices() from AudioDeviceManager::initialise()

I can easily fix it by commenting out that call, but made me think if it’s us doing something the wrong way…

1, We set the DeviceType on the AudioDeviceManager to ASIO
2, We pass a setup object to AudioDeviceManager::initialise()
3, PROBLEM> the second line with pickCurrentDeviceTypeWithDevices() will overwrite the selected DeviceType on the AudioDeviceManager, because it just searches the first Type with devices… In our case it switches to WASAPI type
4, AudioDeviceManager::setAudioDeviceSetup() will drop a “No such device” error because our selected device in the setup object is not found on the list of WASAPI devices. It’s not surprising as it is an ASIO one :slight_smile:

So I guess there is a reason the pickCurrentDeviceTypeWithDevices() was added to the initialise() function, but it breaks code that didn’t thought the DeviceType will be overwritten in it.

Is it a bug or it’s just us using the Manager the wrong way?

1 Like

Thanks for reporting, I think this is indeed a bug. It looks like pickCurrentDeviceTypeWithDevices should avoid picking a new device type if the current device type has usable devices.

I’ve put together a fix, which I expect will make it to develop early next week.

1 Like

Thank you for the quick fix!