Re: how to access HAL buffer timestamps when using AUHAL?
Re: how to access HAL buffer timestamps when using AUHAL?
- Subject: Re: how to access HAL buffer timestamps when using AUHAL?
- From: "Ross Bencina" <email@hidden>
- Date: Tue, 21 Jul 2009 22:04:52 +1000
[sorry for repost looks like my reply didn't get through last time,
questions below...]
Jeff Moore wrote:
On Jul 9, 2009, at 9:40 PM, Ross Bencina wrote:
[snip]
However, the AUHAL render proc looks like this:
OSStatus AudioIOProc( void *inRefCon,
AudioUnitRenderActionFlags *ioActionFlags,
const AudioTimeStamp *inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList *ioData );
I can't find documentation for what inTimeStamp means in this context.
Could someone please clarify the meaning of it for me?
AUHAL has it's own management of it's timeline so that it can do things
like account for dropped samples due to overloads or other changes in
state, not to mention any rate conversion that it might be doing. To get
it to pass along the HAL's timestamps, you can set the property,
kAudioOutputUnitProperty_StartTimestampsAtZero, to false.
Thanks Jeff
At the moment I am interested in mHostTime, not the sample counters, so I'm
guessing that kAudioOutputUnitProperty_StartTimestampsAtZero is not
relevant.
From what you say above, I have drawn the following three conclusions. Could
you please confirm that they are correct?
1. In an AUHAL _output_ AudioIOProc, inTimeStamp->mHostTime is the host time
at which the first sample of the ioBuffer will enter the hardware. This is
the same as the definition for inOutputTime->mHostTime in the HAL IOProc
(except for SRC compensation see below).
2. In an AUHAL _input_ AudioIOProc, inTimeStamp->mHostTime is the host time
at which the first sample of the ioBuffer was received by the driver stack
from the hardware. This is the same as the definition for
inInputTime->mHostTime in the HAL IOProc (except for SRC compensation see
below).
3. In both of the above cases (1 and 2), AUHAL may addjust these mHostTime
timestamps to account for sample rate conversion and buffer underrun/overrun
reset conditions if necessary.
Is any of this documented? I couldn't find it in the online docs.
Is there any way to query CoreAudio for the hardware latency? e.g. the time
difference from when a sample enters the audio hardware at
inOutputTime->mHostTime to when it appears as a voltage or optical impulse
on the physical output?
I don't believe that AUHAL provides any access to the now time stamp.
We can probably get away with AudioGetCurrentHostTime() for this.
Thanks!
Ross.
_______________________________________________
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