How best to handle AirPods audio glitches in Game Mode?

Question

Created Sep ’24

Replies 1

Boosts 0

Participants 1

Hello! The new lower latency support for AirPods in Game Mode is impressive, but I'm not sure of the best way to handle the transition into/out of Game Mode while audio is playing. In order to lower the latency, the system appears to drop some number of samples, with the result being a good deal less latency. My use case is macOS where it's easier to switch in/out of the fullscreen game (a simple swipe left), thus causing more issues for Game Mode since the audio is playing the entire time. It would be nice if offscreen games could remain in game mode, but I understand not wanting to give developers that control.

Are there any best practices for avoiding or masking the audio glitch caused by this skip-ahead? Is there a system event I can receive to know when Game Mode is about to be enabled or disabled, where I could perhaps fade out the audio? My callback checks the inTimestamp->mSampleTime value to detect gaps, but it only rarely detects a Game Mode gap, even though the audio skip-ahead always happens.

BTW, I am currently only developing on macOS (15.0) and I'm working at a low level with AudioUnit callbacks and a SpatialMixer. I am not currently using any higher-level audio APIs.

And here's a few questions I don't necessarily expect answers to, but it doesn't hurt to ask: Is there any additional technical details about how this latency reduction works, or exactly how much of a reduction is achieved (or said another way, how many samples are dropped)? How much does this affect AirPods battery life? And finally, is there a way to query the actual latency value? I check the value for kAudioDevicePropertyLatency but it seems to always report 160ms for AirPods. Thanks!

Boost

Answer 1

andygrundman OP

Oct ’24

This may not the right place to discuss this, but I wanted to add some additional info I've found while looking through log messages. While using AirPods on Mac and playing audio being routed from Apple TV via AirPlay Receiver, I launched an app that triggers game mode. An easy one that triggers game mode but doesn't actually do anything else is the Steam Link app. Notably, the audio being played during this time played without glitches despite the latency being reduced. The log explains how, and even gives us a hint into the latency numbers at play here:

BTAudio      | In ear-Latency change received from BTServer, latency 151MSec
BTAudio      | latencyMode received from : 2
Server.A2DP  | Dynamic Latency settting flush timeout to 60 ms
BTAudio      | audio delivery speed Latency Target 81, Currently running Running, multiplier 1.100000
Server.A2DP  | Dynamic Latency: Request JBL  Down by 81Msec
Server.A2DP  | Initiate Audio Delivery Speed Change Latency change target=81
Server.A2DP  | Dynamic Latency received system 'audio speed change complete' notification from HAL on a2dpHandle 1, status 1
Server.A2DP  | Initiate Audio Delivery Speed Change Latency change target=0
Server.Audio | Timed audio delivery speed modification completed
BTAudio      | audio delivery speed Latency Target 0, Currently running Not Running, multiplier 1.000000
BTAudio      | In ear-Latency change received from BTServer, latency 60MSec
Server.Audio | Low Latency Game a2dpDynamicLatencyTransitionCompleted new latencymode: 1

Neat! A 10% speed change is a good way to mask the problem. And a full 100ms reduction in latency! Is there a chance that apps using higher-level audio APIs get this for free? I am ok if the price for using the low-level AudioUnit API is that I need to roll my own solution, I'm just looking for just a bit of documentation and maybe some sample code.

Side note: I often have the Apple TV configured to route audio to both the Mac and the HDMI out, where the HDMI audio plays in sync with the audio from the Mac's AirPods. This is a great hidden feature, and of course Game Mode when this latency transition happens, the Apple TV isn't aware of it and ends up slightly behind the Mac/AirPods. An extreme edge case at this point, but handled well without any noticeable audio glitches.

0