Mixxx snapshots do not ask for microphone access on macOS (regression)

[fwcd]

Bug Description

The most recent main snapshot of Mixxx does not ask for microphone access on macOS, making it impossible to use it in Mixxx (or associated features such as vinyl control). The stable 2.3 does correctly ask for this permission, so I assume this is a regression:

The issue occurs both on the official Intel builds and unofficial arm64 builds, the credits for discovering this issue go to @npes-95:

• App does not request microphone access. fwcd/m1xxx#26

Interestingly, once a user has accepted the microphone access (e.g. by opening Mixxx 2.3), the microphone will work correctly in recent snapshots of Mixxx too.

Note: In case anyone who already has accepted the permission wants to try this out, the command tccutil reset Microphone org.mixxx.Mixxx will reset the permission

Version

2.4-alpha-1420-gceaedb8443 (the most recent main)

OS

macOS 13.2.1

[fwcd]

This seems to be some form of sandboxing issue, building the most recent main as a non-packaged executable and running it from the command-line also asks for the permissions correctly.

One solution would be to ask for permission explicitly using Objective-C++ through the AVFoundation framework (see here), but perhaps there's a less involved way to achieve this.

[daschuer]

Does this audacity guide also apply to Mixxx?
https://manual.audacityteam.org/man/faq_recording_troubleshooting.html#Why_do_I_get_a_flat_line_and_no_sound_when_I_record_on_Mac.3F

It this discussion related?
https://mixxx.discourse.group/t/macos-catalina-portaudio-errors/18514

[fwcd]

I believe the issue with the Audacity guide is that Mixxx doesn't even show up in the settings if the permission was never requested.

I don't think it is an issue with the actual IO either, since the microphone works fine on recent snapshots if the user manages to add this microphone permission for org.mixxx.Mixxx to the OS's privacy database in some other way e.g. by launching the older 2.3 first.

[daschuer]

In Mixxx we write a plist file.
https://github.com/mixxxdj/mixxx/blob/ceaedb8443714459bc3544faab957d6903eba7b3/packaging/macos/bundle.plist.in

Does is help to add NSMicrophoneUsageDescription there?
https://github.com/seananocoistin/audacity/blob/9cf80a41eee4997cdfc696ba4ad41a4bbab355cf/mac/Info.plist#L235

With Qt 6.5 there will be permissions API https://www.qt.io/blog/permission-apis-in-qt-6.5
https://github.com/qt/qtbase/blob/e7b8b7bfbe6fbcf2ecaccc4c47c09bd34ee26d8c/src/corelib/platform/darwin/qdarwinpermissionplugin.mm

[fwcd]

Good catch, adding a NSMicrophoneUsageDescription did fix it. I vaguely recall that Apple added this policy of requiring such a description for iOS apps a while back too. I'll open a PR for this.

[daschuer]

OK, the first part id fixed. How does Mixxx behave if the user reject the microphone access? Is There something we may implement?
Can we file another issue for it and close this?

[fwcd]

Everything works fine, as if the microphone would only record silence. This is the current behavior if the user isn't prompted at all.

[daschuer]

Can we detect the situation and warn the user as a feature utilizing AVFoundation?

[fwcd]

Yes, we could probably detect if they rejected the permission with AVFoundation and if they try to use the microphone anyway, point them to the system settings (perhaps even deep-link to it) where they can change the permission. I'd move that to a separate issue though since it doesn't relate to any regression, the 2.3, main and earlier versions all behaved this way already.

[fwcd]

Note that to integrate Objective-C++ we need a slightly modified clang-format config. #11353 and #4809 both bundle this patch, if we intend to use Objective-C++ in more placed, I could look into splitting that out into a separate PR though to avoid duplication and potential merge conflicts.

[daschuer]

I have just filed #11370 for the remaining work so we can close this.