Re: AudioDeviceGetCurrentTime after headphone plug/unplug
Re: AudioDeviceGetCurrentTime after headphone plug/unplug
- Subject: Re: AudioDeviceGetCurrentTime after headphone plug/unplug
- From: Jeff Moore <email@hidden>
- Date: Thu, 18 Jan 2007 16:29:36 -0800
Yup. That's a pretty good idea. AUHAL should have a property that can
return the current time as filtered through it's AUTimestampGenerator
math and returns sample times in the same base as what you get on it's
IO callbacks.
That said, I'd like to talk a little bit about what
AudioDeviceGetCurrentTime() actually does so that you have some idea
about what you need to do in the mean time. As you know,
AudioDeviceGetCurrentTime() returns an AudioTimeStamp populated with
the time values requested by the caller. Usually, the caller is
interested in the current sample time, which is calculated based on
the current host time and the currently observed number of host ticks
per sample. The math looks basically like this (which is a simple
linear projection):
S = S0 + R * (H - H0)
Where S is the calculated sample time. S0 is the anchoring sample
time. R is the number of samples per host tick. H is the current host
time and H0 is the anchoring host time.
One thing to notice about this is that H is always available to you.
As such, you can always calculate deltas in sample time based on
deltas in host time using AudioDeviceTranslateTime(). So you also then
know, roughly, how many samples might have been dropped. Given all
this, you can maintain your own internal sample counter that moves at
the same rate as the device but has a differing offset. This is
basically what AUHAL does.
Finally, I'd just like to add that when you see a discontinuity in
time, be it from an overload or a hardware event like plugging in
headphones, you really don't know how many samples the device actually
dropped. The device can easily throw away whole sections of previously
sent audio in it's effort to get back to a normal working state. As
such, applications that are really concerned about synch should
probably view these events as breaking synch, that is, things should
be considered out of synch after such events occur. I have seen apps
handle this by putting up an alert to this effect and then
resynchronizing their entire engine.
On Jan 18, 2007, at 1:10 PM, Bjorn Roche wrote:
On Jan 18, 2007, at 2:58 PM, Jeff Moore wrote:
The API is in the form of the time stamps that AUHAL passes out in
it's various callbacks, which is where it applies the math in
AUTimestampGenerator. To my knowledge, AUHAL does not have a
wrapper for AudioDeviceGetCurrentTime().
It seems a shame that AUHAL offers no reliable way to discover the
time of the device from another thread. I know I could save the
values from the callback, but that is not as accurate as knowing the
actual elapsed time as reported by the soundcard (if in fact that's
what AudioDeviceGetCurrentTime() does). For example, if the
soundcard is processing blocks of size 4096 frames, the current time
measurement could be off by as much as almost 1/10th of a second. It
seems a shame to loose this accuracy as there are applications where
high latency is okay (or even desired) but where timing information
is critical (eg. animation). I think I could provide some
interpolation to workaround this for PortAudio, but it this seems
like a limitation in CoreAudio to me, so I'll file an RFE.
--
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