AudioDeviceManager / AudioDeviceSelectorComponent Bugs + Requests

Development
1

I have been using the AudioDeviceManager and AudioDeviceSelectorComponent extensively for my OS X project, and have found three scenarios which I think are bugs. To prove these bugs, I created a GUI app from Projucer and added an AudioDeviceManager and AudioDeviceSelectorComponent to it in the simplest way. Please see the attached PIP file below so you can try this out for yourself - and run it in Xcode so you can see the DBG output.

JuceADMIssues.h (4.6 KB)

Scenario One: AudioDeviceSelectorComponent Shows the Wrong Device

  1. Let’s say USB Devices A, B, and C exist, and you have selected Device B for input and output in the AudioDeviceSelectorComponent.
  2. Now disconnect Device A (which has nothing to do with the device selected)
  3. The AudioDeviceManager sends a changeListenerCallback to the app.
    The app reads the Xml State and AudioDeviceSetup from the AudioDeviceManager. Both correctly indicate Device B.
  4. However, the AudioDeviceSelectorComponent is now showing Device C in the combo boxes. This is a bug because Device C is not the current device of the AudioDeviceManager.

In this case, the state returned by the AudioDeviceManager is correct, but the AudioDeviceSelectorComponent is not managing its lists properly to keep them synced to the AudioDeviceManager when the list of devices changes.

Scenario Two: The AudioDeviceManager returns the wrong device name

  1. Let’s say USB devices “A”, “B”, and “C” exist, and Device “B” has been selected for input and output in the AudioDeviceSelectorComponent.
  2. Now add another USB device which is identical to Device “B”.
  3. The AudioDeviceManager sends a changeListenerCallback to the app. The app reads the Xml State and AudioDeviceSetup from the AudioDeviceManager. Both indicate Device “B”, but “B” actually no longer exists, because it is now called “B (1)” according to the AudioDeviceSelectorComponent, and according to AudioDeviceIOType::getDeviceNames(). The newly inserted device is called “B (2)”.

In this case, the AudioDeviceManager continues to use the device that was named “B”, and because of this it should return the actual name of the device it is using, not the original name given in the initialise() function. Otherwise, if we use createStateXml to save and restore the AudioDeviceManager next time it is run (which is what it is intended for) then it will try to set it to a device that does not exist - “B”, not “B (1)”. Note that in OS X the names of the two identical USB devices in the drop down menu of the speaker icon (located at the far right of the menu bar at the top) is “B” and “B”.

Scenario Three: Both AudioDeviceSelectorComponent and AudioDeviceManager Indicate the Wrong Devices

  1. Let’s say USB Device A, B and C exist, and Device B is selected for input and output in the AudioDeviceSelectorComponent.
  2. Then disconnect Device B, the currently selected device.
  3. The AudioDeviceManager sends a changeListenerCallback to the app.
  4. The app reads the Xml State and AudioDeviceSetup from the AudioDeviceManager. Both indicate Device B, which does not exist. In other words it generated a callback to say there is a change but when asked what that change was, it tells us the old state for a device that no longer exists, which is no change. Whether this is a bug or not depends on whether the createStateXml function should return the actual state or the its given state.
  5. The AudioDeviceSelectorComponent shows Device C in the combo boxes, as for Scenario One. This is a bug because Device C is not the current device of the AudioDeviceManager - they are both in a contradictory state.

I think the last two scenarios will be resolved if the xml state returned by createStateXML() is consistent with the internal state of the AudioDeviceManager, and therefore suitable for restoring that state later on. To achieve that for Scenario Three, the XML state retrieved from the AudioDeviceManager would have to reflect the truth of the situation by showing input and output device == “” rather than a non-existent device.

Finally, I have a feature request with regards to the AudioDeviceSelectorComponent. At the moment we have the ability to configure it to ignore specific device types. I would also like to be able to configure it to ignore specific input or output (or both) device names.

How to fallback to the default audio device using AudioDeviceManager?
AudioDeviceSelectorComponent issue
2

The AudioDeviceManager is a ChangeBroadcaster and the AudioDeviceSelectorComponent is a ChangeListener. Did you do your tests with adding the selectorComponent as ChangeListener to the AudioDeviceManager, and not only your app?

This should trigger an updateAllControls():

3

Hi Daniel,

To answer your question, I am looking at the AudioDeviceSelectorComponent constructor and it adds itself as a changeListener.

4

Indeed, sorry, I missed that. Was worth a shot though :wink:

1 Like
5

Bump. I would appreciate it if the Roli team could acknowledge the bug report, since it took a lot of work to investigate and prove these issues.

6

Thanks for all your effort!

Sorting this out has been put onto our backlog. It’s pretty important that we sort this issue out, but we just have an unusual amount of higher priority work at the moment.

7

Thanks Tom, much appreciated!

8

This should fix at least the last issue.