PA/CoreAudio uses some "deprecated" APIs which fail on Mac OS 11.0

[PortAudio-admin]

Issue created by @RossBencina

We are using a number of APIs that Apple have marked as deprecated. Some were deprecated in OS X 10.5, OS X 10.6, others in OS X 10.8.

We are using the old APIs for compatibility with older OS X versions. At this stage we wish to continue to support OS X 10.4 and later, so upgrading to APIs added in 10.5 and later is not an option.

The use of deprecated APIs presents two minor issues:

1. The compiler is emitting deprecated warnings, so we can't use -Werror as some would like (this can be addressed by removing -Werror, using -Wno-deprecated or using a #pragma, see: http://stackoverflow.com/questions/2622017/suppressing-deprecated-warnings-in-xcode )
2. The requirement to link with Carbon.framework concerns some people

At this stage there are no obvious technical advantages to moving to the newer APIs. Our plan is to deal with these either when the deprecated APIs are removed completely or when we stop supporting older OS X versions for other reasons. The API functions are listed below along with comments on the migration path.

Core Audio Property Accessor APIs

We use the following old-style HAL Property Accessor functions:

• AudioDeviceGetPropertyInfo
• AudioDeviceGetProperty
• AudioDeviceAddPropertyListener
• AudioDeviceRemovePropertyListener

Since OSX 10.5 these Core Audio HAL APIs have newer direct replacements.
See http://developer.apple.com/library/mac/#technotes/tn2223/_index.html

Audio Converter Services AudioConverterFillBuffer

Since OS X 10.5 AudioConverterFillBuffer is deprecated in favor of AudioConverterFillComplexBuffer.
See https://developer.apple.com/library/mac/#documentation/MusicAudio/Reference/AudioConverterServicesReference/Reference/reference.html

Component Manager APIs for instantiating Audio Units (requires Carbon.framework)

These Component Manager functions are used for instantiating Audio Units. They require linking with Carbon.framework.

• "_CloseComponent", referenced from:

•  _CloseStream in libportaudio.a(pa_mac_core.o)
  

• _OpenAndSetupOneAudioUnit in libportaudio.a(pa_mac_core.o)
• "_FindNextComponent", referenced from:

•  _OpenAndSetupOneAudioUnit in libportaudio.a(pa_mac_core.o)
  

• "_OpenAComponent", referenced from:
  _OpenAndSetupOneAudioUnit in libportaudio.a(pa_mac_core.o)

Since OS X 10.6 they are superseded by functions in Audio Component Services. The new functions reportedly have the same signatures. We could potentially dynamically load the old or new functions depending on availability (as we do for DirectSound APIs on Windows).
See https://developer.apple.com/library/mac/#documentation/AudioUnit/Reference/AudioComponentServicesReference/Reference/reference.html

Gestalt function (requires Carbon.framework)

We use the Gestalt function to check the OS version to execute some code for OSX10.6 and later.

• "_Gestalt", referenced from:

•  _PaMacCore_Initialize in libportaudio.a(pa_mac_core.o)
  

Since OS X 10.8 the Gestalt function is deprecated. It requires linking with Carbon.framework.
See https://developer.apple.com/library/mac/#documentation/Carbon/Reference/Gestalt_Manager/Reference/reference.html#//apple_ref/doc/uid/TP30000036-CH202-SW1
A thread on Stackoverflow proposes several alternatives to Gestalt(), none of which seem great while Gestalt() is still available: http://stackoverflow.com/questions/11072804/mac-os-x-10-8-replacement-for-gestalt-for-testing-os-version-at-runtime

Note on CF* CoreFoundation APIs

We use a number of Core Foundation functions such as CFString functions, CFRelease etc. These are not deprecated. However, we are currently linking against Carbon.framework for these. We should be linking against CoreFoundation.framework

[RossBencina]

@hoolrory assigned to you as requested.

[philburk]

According to #350, these deprecated calls are causing PortAudio to fail at run-time on Mac OS 11.0!
So we need to bump this up to the highest priority.

@hoolrory - Are you available to work on this? Do you need some helpers?

[jmelas]

Just to clarify: portaudio fails in runtime on macOS 11 only if the program is built against macOS SDK 11.
Latest XCode 12.2 comes with macOS SDK 11.
I downgraded Xcode to version 12.1 which uses 10.15 SDK and then portaudio worked fine on Big Sur!

[philburk]

Thanks for the clarification. It seems we are on the edge of PortAudio not working but have not yet fallen off the edge. I will lower the priority to P2.

[Be-ing]

Just to clarify: portaudio fails in runtime on macOS 11 only if the program is built against macOS SDK 11.

I can confirm this. We are building PortAudio with the macOS 10.15 SDK for Mixxx and users have not reported issues with PortAudio using our builds on macOS 11.

[hoolrory]

@Be-ing @jmelas I previously made changes to address this issue in #338, but I hadn't updated the configure script (we use an Xcode project to build portaudio). I think the changes in #359 should fix this for you

[jmelas]

@hoolrory I have opened a PR with more changes regarding this issue:
#356

[Be-ing]

We are building PortAudio with the macOS 10.15 SDK for Mixxx and users have not reported issues with PortAudio using our builds on macOS 11.

Actually, users on macOS 11 are having issues accessing audio hardware. I am not sure if this is due to this PortAudio issue or the macOS Hardened Runtime. I have enabled both the com.apple.security.device.audio-input and com.apple.security.device.microphone entitlements. I don't see any entitlements related to audio output in Apple's documentation.

[Be-ing]

We are building PortAudio with the macOS 10.15 SDK for Mixxx and users have not reported issues with PortAudio using our builds on macOS 11.

I was wrong about this. GitHub Actions is now using the macOS 11.0 SDK and users have been having issues with it.

[Be-ing]

Fixed by #356.

[philburk]

Closing hits. The deprecated calls have been replaced. The crash when building with Mac SDK 11 seems to be a different problem.

[philburk]

Reopening because Gestalt() is still used in PaMacCore_Initialize().

[jmelas]

We are very close to closing this.

About Gestalt calls my vote is to remove support for OS X 10.5 so that the calls to Gestalt are not needed anymore.
This will greatly simplify code because it will also remove all occurencies of #if MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_6.

[RossBencina]

@jmelas I thought that we already removed support for 10.5

[philburk]

We removed support for 10.4 but kept 10.5
#356 (comment)

[jmelas]

It seems an attempt to remove support for 10.5 was made in PR #469
which was replaced by PR #470 which ended up keeping it.
If you all agree I am happy to create a PR to remove support for 10.5 completely!

[RossBencina]

Resolved by #511 which removes OSX 10.5 compatibility.

[coderprodigy]

||PaMacCore (AUHAL)|| AUHAL component not found.

I am still facing this issue. By reading the whole discussion in this thread and other threads, I came to the understanding that now it works for Mac OS Big Sur, but clearly this is not the case. I have checked the version of portaudio as well. I am running the latest version 19.6 but I am still facing this error. Kindly suggest a workaround.

[saikreddy]

Just to clarify: portaudio fails in runtime on macOS 11 only if the program is built against macOS SDK 11.
Latest XCode 12.2 comes with macOS SDK 11.
I downgraded Xcode to version 12.1 which uses 10.15 SDK and then portaudio worked fine on Big Sur!

Hey i am having the same problem with BigSur. To fix this shall i download Xcode 12.1 or Xcode 12.1.1 Release Candidate?

[simdax]

Hello All

I have the same problem trying porting portaudio to IOS
||PaMacCore (AUHAL)|| AUHAL component not found.

Any idea?