Re: Time in CoreAudio/AudioUnits
Re: Time in CoreAudio/AudioUnits
- Subject: Re: Time in CoreAudio/AudioUnits
- From: Jeff Moore <email@hidden>
- Date: Thu, 17 Feb 2005 12:05:46 -0800
On Feb 17, 2005, at 3:42 AM, Chandrasekhar Ramakrishnan wrote:
Hi all.
I've got a few questions about timestamps in CoreAudio and AudioUnits.
A HAL IOProc gets called with 3 timestamps, one to designate "now",
one capturing when the input data was recorded, and one for when the
first sample will be played (does this mean hit the DAC or leave the
DAC?). Is there a way to access this information from a render
callback connected to an output AudioUnit?
To get the time when the output data will hit the wire, you need to add
the presentation latency (kAudioDevicePropertyLatency) to the output
time stamp (or subtract it from the input time stamp to get when the
input data left the wire). Note that input and output latency can
differ, so be sure to pass the right value to AudioDeviceGetProperty().
Does the rate scaler apply to just the current cycle (i.e., how far
off the nominal sample rate the device is on current invocation of the
IOProc/RenderCallback), or does it incorporate some history? And is
this the same for all devices? The rate scalers from the built-in card
on my Quicksilver G4 jump around a bit, implying the former, but the
ones on my MOTU are quite stable, suggesting either the latter or a
good clock on the device.
The rate scalar is the ratio of the observed host ticks per sample to
the nominal host ticks per sample. That makes it the reciprocal of what
you are thinking of.
The rate scalar is built up from the history of the time stamps the
driver supplies to the HAL and filtered to derive the observed host
ticks per sample value. The history is not very long, so depending on
the quality of the time stamps from the driver, the rate scalar will
bounce around a bit.
And finally, a question not really primarily about timestamps, but
when I pull the plug out of the output jack on the internal sound card
on my Quicksilver G4, the device goes out to lunch for about 500 ms
before it starts requesting data again! Is there a reason for this? I
ran HAL Lab and I saw 'gone', 'jack', 'diff', and 'ssrc'
notifications, but I don't see anything specific to the device taking
a break for 500 ms (perhaps 'diff'?)
When you pull the plug out of the headphone jack on your built-in
hardware, the driver has to reconfigure things in the sound chip. This
includes adding and removing things like volume controls and what not.
The HAL has to update it's internal state to reflect what the new state
of the device is. This process can't happen concurrently with the IO
thread running for any number of reasons, so it gets stopped and then
restarted when things are ready again.
--
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