Meta Audio no longer in active development?
From the v85 release notes: This will be the final version of the Meta XR Audio SDK. We are placing the SDK on feature freeze, meaning no further updates are planned. We cannot guarantee compatibility with future versions of these engines/middleware.Bug reports will be acknowledged but fixes are not guaranteed. Can someone clarify why it's no longer supported? I wanted to use it for my game but it seems it's a very risky choice to use it now as it can broke at any point in future and fixes or updates not guaranteed.
USB: Input-Only Microphone Should Not Mute Built-in Speakers, Technical Analysis & Proposed Fix
When any USB-C audio device is connected to Quest 3 — even an input-only microphone with no speaker/DAC capability — Meta Horizon OS routes ALL audio (both input AND output) to the USB-C port and mutes the built-in headset speakers. This contradicts standard Android AOSP behavior and blocks legitimate professional use cases. The Problem Many professional VR applications need external microphone input (for speech recognition, recording, or communication) while maintaining audio output through the built-in speakers. Examples include therapeutic VR, education, accessibility, content creation, live streaming, and enterprise training. We purchased a USB-C gooseneck microphone that is input-only (no speaker, no DAC, isSink=false). On standard Android devices, connecting this mic only affects audio input — speakers continue working. On Quest 3, the built-in speakers are immediately muted, even though the USB device has zero output capability. What We've Tried (Everything Fails) 1. usb_audio_automatic_routing_disabled=1 (ADB): Does not selectively disable routing — prevents the USB device from registering with AudioService entirely (UsbAlsaManager.selectAlsaDevice() returns early), so setPreferredDevice() cannot find the mic at all. 2. AudioManager.setCommunicationDevice(builtInSpeaker) (API 31+): Only affects USAGE_VOICE_COMMUNICATION streams, not media/game audio. Unity uses FMOD → AAudio (native C layer), which routes through USAGE_GAME — unaffected. 3. AudioTrack.setPreferredDevice(builtInSpeaker): Would require intercepting the engine's internal audio output at the native layer — not feasible, and Quest 3's audio HAL may override it anyway. 4. "External Microphone" toggle (Settings > Advanced, v64+): Enables USB mic recognition only. Does NOT provide split input/output routing. 5. Input-only USB mic (isSource=true, isSink=false): Expected AOSP-compliant behavior (only input rerouted). Built-in speakers are still muted. Root Cause Analysis — AOSP vs. Meta Horizon OS In upstream AOSP, UsbAlsaManager.java checks actual device capabilities via USB Audio Class descriptors: // AOSP: frameworks/base/services/usb/java/com/android/server/usb/UsbAlsaManager.java private void selectAlsaDevice(UsbAlsaDevice alsaDevice) { UsbDescriptorParser parser = alsaDevice.getParser(); if (parser.hasOutput()) { // Only register OUTPUT if USB device has playback capability alsaDevice.startOutput(); } if (parser.hasInput()) { // Only register INPUT if USB device has capture capability alsaDevice.startInput(); } } The AOSP AudioPolicyManager then only reroutes streams matching registered capabilities. An input-only device never triggers checkOutputsForDevice(), so speakers remain active. Meta's Horizon OS overrides this separation. The most likely cause: // Probable Meta override (simplified): void AudioPolicyManager::onNewUsbDevice(audio_devices_t device) { // Does not check if device has output capability setDeviceConnectionState(AUDIO_DEVICE_OUT_SPEAKER, AUDIO_POLICY_DEVICE_STATE_UNAVAILABLE); setDeviceConnectionState(AUDIO_DEVICE_OUT_USB_DEVICE, AUDIO_POLICY_DEVICE_STATE_AVAILABLE); } Proposed Fix Check the USB device's Audio Class descriptors before modifying output routing: void AudioPolicyManager::onNewUsbDevice(const sp<UsbAlsaDevice>& device) { if (device->hasCapture()) { setDeviceConnectionState(AUDIO_DEVICE_IN_USB_DEVICE, AUDIO_POLICY_DEVICE_STATE_AVAILABLE); } if (device->hasPlayback()) { // Route output to USB ONLY if device has output capability setDeviceConnectionState(AUDIO_DEVICE_OUT_USB_DEVICE, AUDIO_POLICY_DEVICE_STATE_AVAILABLE); } // If !hasPlayback(): leave built-in speaker routing UNCHANGED } This is a single conditional check in the audio policy layer. It requires zero UI changes and simply aligns Quest 3 with upstream AOSP behavior. Additional Solutions (If a Broader Fix is Planned) - User-facing setting: Add "Audio Output" under Settings > Sound with options "Headset Speakers" / "USB-C" / "Automatic", independent of input routing. - Developer API: Allow applications to call setPreferredDevice() with routing respected for all audio usages (not just USAGE_VOICE_COMMUNICATION). Impact The Quest 3 hardware is fully capable — speakers and USB operate on independent audio paths. This is purely a software routing policy that could be resolved with a minimal code change. The fix would unblock every developer building applications that need external audio input while maintaining speaker output. Happy to provide dumpsys audio output or USB device descriptors to help diagnose the exact policy override. Related: A similar request was posted on the archived forum: "Request for Enhanced Audio Routing Controls with External Microphones on Meta Quest" (jrb-vr, October 2024) — which received no response.
Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.
Cannot control the volume of voice calls on v85
Hello team, I am developing an application related to WebRTC, and I need to control the voice call volume on Meta Quest 3 (increase, decrease, or mute completely). Everything was fine at first, but after I updated the OS to v85.0, when I turned the volume down to zero using the physical button, the sound on YouTube was muted, but the voice call audio was still present. I was very surprised that even Facebook Messenger behaves the same way. Is this a bug in the OS, or is it a new OS behavior? I couldn't find any related information in the release notes. Please help me. Thank you very much.
Meta XR Audio plugin for Unreal Engine improvements
Hello. Meta XR Audio plugin for Unreal Engine 5.6 (v83) also as other versions stores metaxraudio64.dll in Plugins\MetaXRAudio\Binaries\Win64 It is not an "Unreal way" to store DLLs and also heaving binaries folder for compiled DLLs in repo can deal some troubles with project cleanup and build/compile/cicd etc. It is much better to not have binaries folder in repo and all precompiled libraries should be in plugin folder. I did not found any github repo to make PR for changes i would like you to review. Base idea is to remove Plugins\MetaXRAudio\Binaries\Win64\metaxraudio64.dll and move it to something like Plugins\MetaXRAudio\Source\ThirdParty\MetaXRAudio\Win64 and make it to be copied at build time to Plugins\MetaXRAudio\Binaries\Win64 using built-in UE tools. You can add dedicated module to copy this dll or at least make a small fix in Plugins\MetaXRAudio\Source\MetaXRAudio\MetaXRAudio.Build.cs Line 64 - replace original code: if (CurrentPlatform == UnrealTargetPlatform.Win64) { // Automatically copy DLL to packaged builds RuntimeDependencies.Add(System.IO.Path.Combine(PluginDirectory, "Binaries", "Win64", "metaxraudio64.dll")); AddEngineThirdPartyPrivateStaticDependencies(TargetRules, "DX11Audio"); } with this code: if (CurrentPlatform == UnrealTargetPlatform.Win64) { string DLLName = "metaxraudio64.dll"; string SourceDllPath = System.IO.Path.Combine(PluginDirectory, "Source", "ThirdParty", "MetaXRAudio", "Win64", DLLName); string TargetDllPath = System.IO.Path.Combine(PluginDirectory, "Binaries", "Win64", DLLName); // Add DLL to linker delay-load list with FULL SOURCE PATH //PublicDelayLoadDLLs.Add(SourceDllPath); // RuntimeDependencies to copy DLL to PLUGIN binaries RuntimeDependencies.Add(TargetDllPath, SourceDllPath); // Add to receipt for BuildGraph awareness //AdditionalPropertiesForReceipt.Add("BuildProduct", SourceDllPath); // Third-party dependencies AddEngineThirdPartyPrivateStaticDependencies(TargetRules, "DX11Audio"); } This will copy metaxraudio64.dll from Plugins\MetaXRAudio\Source\ThirdParty\MetaXRAudio\Win64 to Plugins\MetaXRAudio\Binaries\Win64 at every build. Checked with PC, CICD, UnrealGameSync (UGS) so it covers all cases. This is a small fix i am asking you to do please and it will help developers have less pain in head. P.S. the same or similar way you can move headers and .so libs from Plugins\MetaXRAudio\Source\MetaXRAudio\Private\LibMetaXRAudio which is also not a good place to store it, and also not an "Unreal way". You can move everything to Plugins\MetaXRAudio\Source\ThirdParty\MetaXRAudio\{platform_name} Please think about it.There's no way to download SDK 83.0.2
meta announced SDK Version 83.0.2 below, but there's no correct link. https://developers.meta.com/horizon/downloads/package/meta-xr-sdk-all-in-one-upm/ since the unity asset store's version is not updated( it's still 83.0.1), there seems to be no way to download Version 83.0.2. Also, I can't find Version 83.0.2 on Unity package manager. Why does meta announced Version 83.0.2 only on release note? I'm so confused. if anyone here successes in downloading 83.0.2, could you tell me how to do that?What are recommended headphones for spatial audio supported by the Meta Audio XR SDK in Unity?
I'd like to find the best headphones (not in-ear) for spatial audio experiences supported by the Meta XR Audio SDK and meta quest 3 headsets. Are there any directly recommended by Meta? More context: I'm developing a spatial audio experience in Unity and I'm using a standard meta quest 3 headset.
META Glasses SDK access
I've recently been trying to code some projects with my new Gen 2 Wayfarer Rayban glasses but haven't been able to get access to the SDK (except for the public one on GitHub). I’ve reviewed the Wearables Device Access Toolkit documentation and sample iOS projects and am interested in building real-time accessibility applications. Could someone clarify how developers can request access to any gated SDK capabilities (such as live camera streams or audio interfaces), or whether there is a formal application or beta program for expanded access? Any guidance would be appreciated. For more information, I also tried going in-person to the META Lab @ NYC and also emailed Conor Griffiths to see if I could get help but haven't gotten a reply. Happy Holidays everyone and thank you for the help!
