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: Dale Curtis <email@hidden>
- Date: Mon, 31 Jul 2017 09:16:32 -0700
Thanks both for the replies. I'm glad to hear we what we have is as correct
as can be. Especially since I wrote it long enough ago that I couldn't
remember why we did this :) I'll update the code to include a link to this
discussion for future reference.
- dale
On Sun, Jul 30, 2017 at 9:32 PM, Paul Davis <email@hidden>
wrote:
> 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:
>> 40linuxaudiosystems.com
>>
>> 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