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 protected]> 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 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/dkling >> ler%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]
