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: Paul Davis <email@hidden>
- Date: Mon, 31 Jul 2017 00:32:49 -0400
One small note: the description offered by Dan regarding latency figures
from a device driver are only correct if the device includes (and correctly
reports on) its own DA/AD conversion. If you use external converters (e.g.
the audio interface has a digital connection to your converters), then the
device driver cannot report on the latency caused by the converters, and
the only way to get a correct number is to actually measure it with a
loopback cable/signal pathway. There is open source code around that
explains how to do this which you consider looking at.
On Sat, Jul 29, 2017 at 7:51 PM, Dan Klingler <email@hidden> wrote:
> 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
>
> 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
>
> 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:
> email@hidden
>
> 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:
> email@hidden
>
> 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