Implement get_latency method for coreaudio on MacOS#119444
Open
mattbearman wants to merge 1 commit into
Open
Conversation
mattbearman
force-pushed
the
fix-core-audio-get-latency
branch
from
bc1e22a to
64f9395
Compare
mattbearman
force-pushed
the
fix-core-audio-get-latency
branch
3 times, most recently
from
44f4a9e to
ca1139f
Compare
mattbearman
force-pushed
the
fix-core-audio-get-latency
branch
from
ca1139f to
ad4a7ee
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem(s) does this PR solve?
Currently calling
AudioServer.get_output_latency()on a Mac will always return0, as theget_latency()function is not defined in the CoreAudio driver, so it falls back to the virtual function inaudio_server.h, which just returns0This PR adds the
get_latency()function in CoreAudio (for Mac only, other devices using CoreAudio, such as iOS, will still report 0 - I'll tackle that in a future PR)I've tested this on a 2023 M3 MacBook Pro running MacOS 15, and a 2017 Intel MacBook Pro running MacOS 13, with a few different audio devices on each (built in speakers, headphones, USB interfaces), and the latency reported appeared correct in all instances
Additional information
The basis for the latency calculations came from this discussion on the JUCE framework forum, as well as the CoreAudio docs and my own experimentation
Regarding stream latency, in an ideal world when there are multiple streams we'd figure out which stream was currently being used, however I couldn't find a reliable way to do that. The approach here of using the maximum reported stream latency seems like a safe compromise, especially considering every single external audio device I tested reported a stream latency of zero anyway
In my testing only the built in audio devices actually report a stream latency, and they only ever have the one stream 🤷
AI disclosure
I didn't any AI used in the development of this