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 protected]> 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 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 > > 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 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/ > paul%40linuxaudiosystems.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]
