Re: AUTimePitch + input notification
Re: AUTimePitch + input notification
- Subject: Re: AUTimePitch + input notification
- From: John Clayton <email@hidden>
- Date: Thu, 18 Dec 2008 13:48:14 +0100
Cheers. I did some tests and found some issues with the callback
(which is probably another way of saying my code has bugs?).
In this callback, where by AUTimePitch is set to process at a rate of
1.0 - and I simply play a movie through my graph logging out various
data during the callbacks, the callback always gets approx 470 frames
of input data. While the callback does tell me which inputFrame has
been used, it effectively appears to process audio data more slowly
than what I expect. I expect it to keep up with the output HAL in
terms of total frames being processed / time.
I expect that because the sample rate for the entire graph is 44.1 khz.
the output HAL always gets 512 framer per callback
so it appears (to the code) that the audio data is moving through the
graph more slowly - although everything sounds OK from what I can
hear. Is this is known noob gotcha? or am I missing something obvious?
Thanks
--
John Clayton
Skype: johncclayton
On 15/12/2008, at 8:42 PM, William Stewart wrote:
On Dec 14, 2008, at 11:30 PM, John Clayton wrote:
Hi All,
My goal is to sync up the sound being heard to the frames of video
being displayed from a single QT movie. Sound is played via core-
audio and can be pitch/rate shifted via an AUTimePitch - which
makes the real progress through time variable (i do however know
exactly when these rate changes will take place). The core-audio
graph looks a bit like this:
QT Movie -> AUTimePitch -> Dynamics Processor -> Merge -> Output HAL
My thinking so far, is that the best (only?) unit of measurement
would be 'number of frames processed' by the input callback of the
AUTimePitch unit. In that way, I'd know how much data has been
requested from the movie, but its uncertain how much data (and thus
time latency) is introduced by the inner working of the AUTimePitch.
Is there a way to accurately work out the exact frame number of
audio that is presently coming of the speakers assuming the chain
above? If yes, then I can simply use that value + total number of
frames in the movie to work out the right video frame that should
be displayed (taking the graph and video display latency into
effect as well at some point - but lets crawl first, run later).
There's a property on the AUTimePitch that describes what sample
from the input is represented in a given output buffer (it describes
the first sample of the output buffer has this input sample):
@constant kAudioUnitProperty_InputSamplesInOutput
Scope: Global
Value Type: struct AUInputSamplesInOutputCallbackStruct
Access: read/write
An audio unit calls this callback at the end of its render
call. The audio unit supplies the
following information:
outputTime - The timestamp passed in to the audio unit's
render call. This timestamp
represents the time of the first output sample.
inputSample - The sample number of the first input sample
that is present in the output
audio.
numInputSamples - The number of input samples that were used
and are present in the output
audio.
This property allows a host application to determine which
input samples correspond to a sample
in the output buffer. It is useful only for audio units that
do time-stretching, such as the
AUVaripseed and AUTimePitch units, where the relationship
between input and output samples is
non-trivial. For these units, the range of input samples that
correspond to an output buffer
typically differs from the range of input samples that were
pulled for that render call.
This difference arises because of internal buffering,
processing latency, and other factors.
Bill
_______________________________________________
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