Re: kAudioUnitProperty_PresentationLatency usage
Re: kAudioUnitProperty_PresentationLatency usage
- Subject: Re: kAudioUnitProperty_PresentationLatency usage
- From: Shaun Wexler <email@hidden>
- Date: Tue, 18 Oct 2005 11:22:33 -0700
On Oct 17, 2005, at 1:31 PM, Marc Poirier wrote:
I'm a little unsure of how to use the
kAudioUnitProperty_PresentationLatency property. In my scenario, I
have an AU that provides a visual meters for the input level and
the output level. What I've been doing is to adjust the display of
the input level by the value for PresentationLatency on the input
scope, and adjust the display of the output level by the value for
PresentationLatency on the output scope. But then I started
doubting that this makes sense. My AU itself has no latency in its
DSP, so why would I ever want a different PresentationLatency
latency value for input vs. output? In cases where my AU might be
getting different values, then what that would do would be to make
the level meters out of sync with each other. So far as my AU is
concerned, the input is occurring at the same time that its
corresponding output is being generated. So then I wonder, do I
just want to offset both displays by PresentationLatency on the
output scope? Or do I want to offset both displays by the sum of
the PresentationLatency on both input and output scopes? Or
something else? I am very unsure...
Input meters should probably be displayed immediately. Output is
more complicated. You're probably averaging over the full buffer
period since that will be smaller than the display's max refresh rate
period (ie 16.7 ms or less), plus there is additional CPU/GPU latency
to render and wait for VBL to flush to screen. You have to deduct
the estimated average drawing latency from your presentation latency,
and only apply delay to the meter if non-negative.
For example, MacFOH has an audio input-to-pixel latency between 17 ms
and 29 ms, at 60 Hz VBL. Audio at 86 buffers per second (44.1k) is
processed 43% faster than video frames of a 60 Hz LCD: 512 samples
plus input latency/offset, plus between zero and one frames at the
screen's refresh rate, so (I think this is correct): 60/abs(86-60) =
2.3 frames per second where the audio misses the VBL and has to wait
until the next frame to be displayed; otherwise it analyzes and
displays the response "instantly" in the eyes of the viewer.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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