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: Jeff Moore <email@hidden>
- Date: Tue, 21 Jul 2009 09:22:31 -0700
On Jul 21, 2009, at 5:04 AM, Ross Bencina wrote:
[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.
There may be some synthesizing of the host times when there is rate
conversion going on. There may also be some synthesizing of time
stamps to reconcile overloads and what not. So no, I'm not so sure
that it isn't 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.
This all seems generally correct modulo the differences I mentioned
above.
Is any of this documented? I couldn't find it in the online docs.
I don't know what's in our documentation about this, but most of this
has been talked through at WWDC a few times over the years and it has
definitely been discussed here before many times.
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?
The HAL provides the properties kAudioDevicePropertyLatency and
kAudioStreamPropertyLatency. The latency for any particular channel on
an audio device is the sum of the device latency and the latency of
the stream the channel is in.
Note that AUHAL proxies most of the HAL's properties, so you can
access them straight from AUHAL without dipping down to the HAL's API.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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