Mac Catalyst Audio Device Name CADefaultDeviceAggregate-xxxx-x

In a way, it seems to be an architecture mismatch between macOS and iOS audio. On iOS, there can be multiple audio routes (that is, possible paths from input to output ports). On macOS, there is only one audio route, from the user's selected input device to the user's selected output device. There's no system reason to switch port on macOS, unlike iOS, where the system switches between ports a lot.

In a way, that's fine on the macOS side as far as it goes — it makes sure the defaults that are actually used are the defaults that the user chose. However, it would be helpful if individual inputs and output devices were also available as input and output ports in Catalyst. There's a similar problem with AVAudioEngine's input and output nodes under Catalyst.

I think this mainly represents a lack of foresight (or perhaps time ran out before these niceties could be added). File a bug report. It does no harm to nudge the audio engineers in the right direction. 🙂

It turns out that a lot more is possible with the CoreAudio framework in Catalyst than in iOS. So, we can get all the info we need through CoreAudio in the Mac version of the app. We can even allow the user to choose the selected audio input and output devices through our own app.

Here's a simple Swift example to get the name and UID of the current input device (accessible from our existing Objective-C code):

@objc open class func getSelectedInputDeviceInfo() -> [String: Any]
  {
  let keys = FSTCAKey()
  var devInfo:[String: Any] = [keys.inputDeviceName: "Audio Input", keys.inputDeviceUID: "Audio Input"]

  var deviceId = AudioDeviceID(0);
  var deviceSize = UInt32(MemoryLayout.size(ofValue: deviceId));
  var address = AudioObjectPropertyAddress(mSelector: kAudioHardwarePropertyDefaultInputDevice, mScope: kAudioObjectPropertyScopeGlobal, mElement: kAudioObjectPropertyElementMaster);
  var err = AudioObjectGetPropertyData(AudioObjectID(kAudioObjectSystemObject), &address, 0, nil, &deviceSize, &deviceId);

  if ( err == 0)
  {
  devInfo[keys.inputDeviceID] = deviceId

  address.mSelector = kAudioDevicePropertyDeviceNameCFString
  var deviceName = "" as CFString
  deviceSize = UInt32(MemoryLayout.size(ofValue: deviceName))
  err = AudioObjectGetPropertyData( deviceId, &address, 0, nil, &deviceSize, &deviceName)
  if (err == 0)
  {
  devInfo[keys.inputDeviceName] = deviceName as String
  print("### current input device: \(deviceName) ")
  }
  address.mSelector = kAudioDevicePropertyDeviceUID
  err = AudioObjectGetPropertyData( deviceId, &address, 0, nil, &deviceSize, &deviceName)
  if (err == 0)
  {
  devInfo[keys.inputDeviceUID] = deviceName as String
  print("### current input device UID: \(deviceName) ")
  }
  }

  return devInfo
  }

The name and UID returned from CoreAudio give us what we were hoping to get from AVAudioSession.

On the Mac, it is possible for an app to choose one or more audio input and/or output devices to work with, independent of the system input/output device selection. However, I don't see any reason why a Mac Catalyst audio app couldn't or shouldn't operate the same way on Mac as it does on iPad (even if it isn't as elegant as a native Mac app's ability to work with audio devices, independent of the system selection).

In any case, I did submit a formal request to Apple (FB7328546) to provide similar behavior in AVAudioSession's 'availableInputs' property.

Also, although I have been using the RemoteIO audio unit to interact with the selected audio devices, I did test this issue with AVAudioEngine and got the same result for the input device name ('CADefaultDeviceAggregate-xxxx-x').

So, basically, we are back to having two different code branches - one for selecting input device on MacOS and another for iOS?

I was really hoping I can write the same code for both systems...

Do you have to check at run time what system the app is running on?

Or at compile time using pecompile directives?