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

General JUCE discussion
1

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))
    {
        RuntimePermissions::request(RuntimePermissions::recordAudio,
            [&](bool granted) { setAudioChannels(granted ? REQUESTED_CHANNEL_COUNT : 0, REQUESTED_CHANNEL_COUNT); });
    }
    else
    {
        // Specify the number of input and output channels that we want to open
        setAudioChannels(REQUESTED_CHANNEL_COUNT, REQUESTED_CHANNEL_COUNT);
    }

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());