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 protected]> 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 protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/dklingler%40apple.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
