Xemu forces AirPods/BT headsets to 24Khz audio on macOS

[schm1dtmac]

Bug Description

When Xemu is launched, despite it not needing microphone support for anything currently and not appearing to use the mic (no signs of it in the Mac menu bar), my AirPods 2 freak out as if Xemu actually was using the mic. That causes everything to sound awful as is typical for the low-quality 24Khz BT profile used when the mic is active.

Very strange, given that Xemu doesn't have mic support afaik. It doesn't even prompt for mic permissions on macOS, so there should be no way for it to actually access the mic. I expect other BT headsets may also be affected on macOS albeit they may drop to 16Khz or even 8Khz audio, which would be far less usable. Can't test other OSes so I've got no idea if this is macOS-specific.

Expected Behavior

Xemu shouldn't cause my AirPods to switch away from their stereo/A2DP BT audio profile (the high quality one) to the 24Khz one used when the mic is active, unless mic support gets added (e.g. for Communicator support) and is explicitly enabled by the user in future.

xemu Version

0.8.1

System Information

OS: macOS 15.2 Sequoia
SOC: Apple M2

Additional Context

No response

[schm1dtmac]

Did some more testing/checks, turns out this was a regression introduced by Xemu 0.7.99 (which is affected by the bug, whilst 0.7.98 and any older builds I tested aren't affected). That update merged a newer QEMU version, 7.2.4, so I kinda have a feeling this was an upstream issue inherited by Xemu. @mborgerson should I close the issue if it most likely is an upstream bug and report to QEMU instead?

[mborgerson]

@schm1dtmac I agree, that's annoying. Thanks for hunting that down! Let's:

• Keep the issue open until we fix it in xemu
• Investigate further and fix the issue in xemu
• Check if the issue is present in vanilla QEMU, whether it is resolved upstream or not (xemu is a few versions behind at this point) and report if necessary

[Fabxx]

Happens on linux as well with JBA WAVE FLEX headphones on bluetooth. Switches from SBC-XQ codec to mSBC codec

[schm1dtmac]

Had a look at what the macOS system logs in Console.app report, it seems Xemu/Qemu is 100% attempting to configure a microphone for some reason, but this is invisible to the user on Mac because Info.plist lacks the required entries for macOS to prompt the user for mic permissions. For other apps that use the mic explicitly and include the necessary Info.plist entries, macOS prompts the user as soon as the app tries using the mic.

The above should cause macOS to auto-reject the request silently for Xemu, but it still causes AirPods to change to the HFP/24Khz mode. Adding the necessary key to Info.plist (NSMicrophoneUsageDescription) and resigning causes Xemu to throw up a mic permissions prompt, confirming my above suspicions. Denying xemu permission here behaves as before, AirPods still switch to the HFP/24Khz mode. Easiest solution is finding where it is that the mic/input device stuff is being configured and switching it all off for now (until Communicator support gets merged in future ig with #1188).

[schm1dtmac]

Luckily it seems that one of the changes that came from merging QEMU 9.2.0 in #1849 fixed the issue, a rather ironic fix I have to say given how the issue came about.