AudioDeviceManager gets tripped up by empty (but available) device Types

General JUCE discussion
1

(I first hit this with JUCE 5.4.7, but I’ve read through the latest code in the repo and there’s nothing different in the AudioDeviceManager class that would lead me to believe things have changed in 6.0.8 or later.)

When it needs to default the current audio device, in the absence of any other configuration the AudioDeviceManager will fall back to choosing the first device for the first available device type.

That’s somewhat unfortunate if you happen to find yourself in the admittedly-unusual situation where the first audio device type contains NO devices at all, since AudioDeviceManager will nevertheless set the first type in availableDeviceTypes as current, whenever any code wants to createDeviceTypesIfNeeded():

juce_AudioDeviceManager.cpp@100:115

void AudioDeviceManager::createDeviceTypesIfNeeded()
{
    if (availableDeviceTypes.size() == 0)
    {
        OwnedArray<AudioIODeviceType> types;
        createAudioDeviceTypes (types);

        for (auto* t : types)
            addAudioDeviceType (std::unique_ptr<AudioIODeviceType> (t));

        types.clear (false);

        if (auto* first = availableDeviceTypes.getFirst())
            currentDeviceType = first->getTypeName();
    }
}

And code that sets the default device tends to query the currentDeviceType for a list of devices to choose from.

I ran into this building a command-line tool under MinGW on Win10 — because the executable isn’t compiled as a WIN32 application, it won’t detect any WASAPI devices, but the type is still created as the first one in the list — it simply contains zero devices. Whereas the DirectSound type does contain a working and usable device, but it’ll be ignored unless explicitly requested.

For that particular tool I worked around this in the supported manner: by subclassing the AudioDeviceManager, overriding createAudioDeviceTypes(), and removing the WASAPI type instantiations because I know that code will never be able to see WASAPI devices. The API is, as always, well-designed and conducive to such needs.

From reading the code it seems I could’ve also worked around it by passing "*" as the preferredDefaultDeviceName argument to AudioDeviceManager::initialise(), instead of omitting it and passing the default empty string, since having a non-empty preferredDefaultDeviceName will cause initialiseDefault() to walk the entire list of availableDeviceTypes looking for matching devices.

But it strikes me that the AudioDeviceManager should be able to notice any AudioIODeviceType* types that return an empty list for type->getDeviceNames(), and do any of the following in response:

  1. Skip over that type when defaulting the currentDeviceType, if there are more types in the availableDeviceTypes list.
  2. Sort the 0-device AudioIODeviceType*s to the end of the availableDeviceTypes list, instead of preserving the original configuration order, so that any types with detected devices are given priority.
  3. Remove the “empty” types from availableDeviceTypes entirely. (I’m not so sure about this one, could there be some types that come up with no devices initially, but are later populated in response to some sort of device activation/initialization? I assume probably yes.)
2

So, it turns out I’m wrong about that part. Because this device-type switching is kind of a mess.

If initialise() is called with a preferredDefaultDeviceName, it’ll be passed to initialiseDefault() which will scan all available types for a matching name. If it finds one, it’ll store that name — ONLY the name — in setup.outputDeviceName and/or setup.InputDeviceName as indicated by the channel count requested.

But then later, when setAudioDeviceSetup() is called with the resulting AudioSetup struct, it checks only the current device type for setup.{input,output}DeviceName, meaning that if the name was matched on some other type it’s going to fail and produce a "No such device: " message.

This is made slightly more annoying by the fact that AudioDeviceManager::findType(String inputDeviceName, String outputDeviceName) is PRIVATE (WHY???), so I’ll have to reimplement that in the caller if I want to discover the correct type and set it manually, as a workaround.

3

If you know your app will never use WASAPI devices, you can disable them completely by setting JUCE_WASAPI to 0 in your project’s preprocessor definitions.

I’ve also made some changes to the AudioDeviceManager so that it will initially attempt to find a device type with some exstant devices.

1 Like
4

Thanks @reuk , those changes look good to me. I think they’ll improve the defaulting process considerably.

The related issue of AudioDeviceSetup storing only the juce::String name of the input and output devices — I suppose that’d be harder to change, huh, given that it’s a public struct?

…The XML configuration does have the ability to store the deviceType, though, so I guess maybe it’s not really an issue. As long as the type-defaulting does sensible things, and XML is used for any stored configurations, the currentDeviceType should be a sensible one by the time AudioDeviceSetups are created for its selected devices.

5

I’m seeing a crash being reported on the Play Store console that seems to happen to many users on many different devices. It’s reported as a SIGSEGV error and the track trace is the following:

backtrace:
#00 pc 0000000000000000
/libjuce_jni.so (offset 0x1000) (juce::AudioDeviceManager::createDeviceTypesIfNeeded())
/libjuce_jni.so (offset 0x1000) (juce::AudioDeviceManager::initialise(int, int, juce::XmlElement const*, bool, juce::String const&, juce::AudioDeviceManager::AudioDeviceSetup const*))
/libjuce_jni.so (offset 0x1000) (SGManager::setAudioChannels(int, int))
/libjuce_jni.so (offset 0x1000) (SGManager::initializeCore())
/libjuce_jni.so (offset 0x1000) (SGManager::initialize())
/libjuce_jni.so (offset 0x1000) (ISInitProgress::run())
/libjuce_jni.so (offset 0x1000) (juce::thread::threadEntryPoint())
/libjuce_jni.so (offset 0x1000) (juce::threadEntryProc(void*)) (SourceCode: include_juce_core.cpp)

That’s all I have to work on. The JUCE code is as per v 6.1.2:

void AudioDeviceManager::createDeviceTypesIfNeeded()
{
if (availableDeviceTypes.size() == 0)
{
OwnedArray types;
createAudioDeviceTypes (types);

    for (auto* t : types)
        addAudioDeviceType (std::unique_ptr<AudioIODeviceType> (t));

    types.clear (false);

    if (auto* first = availableDeviceTypes.getFirst())
        currentDeviceType = first->getTypeName();
}

}

This is on Android, using OBOE, with OPENSL disabled.

And I’m doing a standard initialisation:

void setAudioChannels (int numInputChannels, int numOutputChannels)
{
    String audioError;

    auto setup = deviceManager.getAudioDeviceSetup();

    setup.inputChannels.clear();
    setup.outputChannels.clear();

    setup.inputChannels.setRange (0, numInputChannels, true);
    setup.outputChannels.setRange (0, numOutputChannels, true);

    setup.useDefaultInputChannels = false;

    audioError = deviceManager.initialise (numInputChannels, numOutputChannels, nullptr, true, "", &setup);

    jassert (audioError.isEmpty());
}

Any idea why this would crash?

6

I don’t see anything obvious that might cause a crash there.

I notice there’s a juce::Thread::threadEntryPoint in your stack trace. Are you interacting with the AudioDeviceManager from multiple threads? I wonder whether there is a race on availableDeviceTypes or currentDeviceType.

The function above has changed a bit in the latest version of JUCE, so you could try updating and see whether that resolves the issue. However, if the problem is due to threading, then you’ll likely need to resolve the issue in your own code.

7

Thanks for the feedback. The thread I used to load all the assets of the app after main screen displayed is quite safe, but as you mentioned it I investigated further and could now think of a possibility where the user exits the app while these assets (and the device manager stuff) are being loaded. I kind of overlooked that possibility and this could well be the reason of these crashes.

I’ll post a new update with a consolidated app cancellation while loading and see if these crash reports are still appearing in the logs.