Re: What's the correct way to measure latency of audio input and output?
Re: What's the correct way to measure latency of audio input and output?
- Subject: Re: What's the correct way to measure latency of audio input and output?
- From: Dan Klingler <email@hidden>
- Date: Sun, 30 Jul 2017 00:51:50 +0100
Hi Dale,
For input:
The input timestamp provided to the app in the callback represents the time at
which the first input sample in the buffer was delivered to the driver by the
hardware. This timestamp will be in the past of "now". The driver provides
kAudioDevicePropertyLatency and kAudioStreamPropertyLatency, the sum of which
represents the hardware-specific delay (in samples) between the audio hitting
the mic and landing in the audio driver's buffer. To arrive at the time at
which that audio truly "hit the mic", an app would need to adjust the callback
host time a bit further in the past by kAudioDevicePropertyLatency +
kAudioStreamPropertyLatency (after converting those latencies from samples to
host ticks).
For output:
The output timestamp provided to the app in the callback represents the time at
which the first output sample in the buffer will be consumed by the hardware.
This timestamp will be in the future of "now". The driver provides
kAudioDevicePropertyLatency and kAudioStreamPropertyLatency, the sum of which
represents the hardware-specific delay (in samples) between the audio being
consumed by the hardware and hitting the speaker. To arrive at the time at
which that audio will truly "hit the speaker", an app would need to adjust the
callback host time a bit further in the future by kAudioDevicePropertyLatency +
kAudioStreamPropertyLatency (after converting from samples to host ticks).
I found a couple old email threads that might have additional helpful
information:
https://lists.apple.com/archives/coreaudio-api/2008/Jul/msg00077.html
https://lists.apple.com/archives/coreaudio-api/2009/Jun/msg00148.html
Dan
> On Jul 29, 2017, at 12:30 AM, Dale Curtis <email@hidden> wrote:
>
> I.e. if a sound occurs at time T, how can we determine T during the eventual
> AURenderCallbackStruct::inputProc() callback delivering that audio data?
>
> In Chrome we've always done this by roughly the following calculation:
> T = inTimeStampReceivedByInputProc->mHostTime -
> AudioUnitGetProperty(kAudioUnitProperty_Latency) -
> AudioObjectGetPropertyData(kAudioDevicePropertyLatency);
>
> https://cs.chromium.org/chromium/src/media/audio/mac/audio_low_latency_input_mac.cc?l=1059
>
> <https://cs.chromium.org/chromium/src/media/audio/mac/audio_low_latency_input_mac.cc?l=1059>
>
> Is this actually correct? Specifically, I wonder if we really need to
> manually include the two latency properties or if those are already baked
> into the provided AudioTimeStamp?
>
> Similarly, for output if we render a sound at time T, we expect it to play at
> T = inTimeStampReceivedByInputProc->mHostTime +
> AudioUnitGetProperty(kAudioUnitProperty_Latency) +
> AudioObjectGetPropertyData(kAudioDevicePropertyLatency)
>
> https://cs.chromium.org/chromium/src/media/audio/mac/audio_auhal_mac.cc?l=392
> <https://cs.chromium.org/chromium/src/media/audio/mac/audio_auhal_mac.cc?l=392>
>
> The playout case seems more reasonable to need to include the additional
> latency fields, but again I can't find any documentation suggesting what is
> actually correct. Thanks in advance for any clarity!
>
> - dale
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden