I think I found a bug in default audio initialization on Windows platforms

I think I found a Windows related bug in:
void AudioDeviceManager::insertDefaultDeviceNames (AudioDeviceSetup& setup) const

When the above method gets called via setAudioChannels() during initialization:

    // Some platforms require permissions to open input channels so request that here
    if (juce::RuntimePermissions::isRequired(juce::RuntimePermissions::recordAudio)
        && !juce::RuntimePermissions::isGranted(juce::RuntimePermissions::recordAudio))
            [&](bool granted) { setAudioChannels(granted ? REQUESTED_CHANNEL_COUNT : 0, REQUESTED_CHANNEL_COUNT); });
        // Specify the number of input and output channels that we want to open

The end result on Windows platforms seems to be, that in some cases output device is selected to be audio interface X and audio input device audio interface Y. There are two problems here:

  1. As far as I can tell, Windows doesn’t like to have different audio hardware devices set as input and output at the same time.

  2. In my case audio interface Y doesn’t actually send audio, but is capable of it with certain extra hardware additions.

So as far as I can tell, the default audio initialization in AudioDeviceManager::insertDefaultDeviceNames() isn’t fool proof on Windows platforms.

What ends up happening is the assertion failure on line 73 in file juce_AudioAppComponent.cpp. The function in question is:

void AudioAppComponent::setAudioChannels (int numInputChannels, int numOutputChannels, const XmlElement* const xml)

The exact line is:
Line 73: jassert (audioError.isEmpty());