REPOST: What can cause an AUHAL sample timestamp to jump far into the future?
REPOST: What can cause an AUHAL sample timestamp to jump far into the future?
- Subject: REPOST: What can cause an AUHAL sample timestamp to jump far into the future?
- From: Christopher Ashworth <email@hidden>
- Date: Sat, 21 Mar 2009 09:19:47 -0400
Hi,
Hoping there might be some shred of a tip someone could give about why
sample timestamps coming in through an AUHAL are jumping hundreds of
years into the future.
Alternate questions that might be helpful:
- Is this something anyone else has ever seen?
- Is the AUHAL timestamp generated relatively independently from the
device driver, or would variations in the behavior of the device
driver lead to variations in the behavior of the timestamps? (i.e.
could the cause trace back "through" the AUHAL to a particular
manufacturer's driver.)
Best,
Chris
On Mar 16, 2009, at 12:34 PM, Christopher Ashworth wrote:
Hi All,
I've got an AUHAL output unit connected to a Matrix Mixer unit. The
mixer has multiple busses, and I feed multiple audio files into the
AUHAL output via those busses.
I'm using the inTimeStamp->mSampleTime of the render callback to
synchronize these multiple streams of audio. When the app is first
launched it creates an AUHAL output for each attached device and
starts the device. When playback for a stream of audio begins, the
stream is "anchored" on a starting sample for its device, and as the
app delivers frames of audio it counts up from that starting
sample. It pitches frames or delays frames as necessary to make
sure it's sample-accurate synced with any other streams that were
anchored to that same starting sample on that device.
This generally works great. However, I'm getting intermittent
reports that something is occasionally going wrong.
From console logs sent to me by users, it appears that the sample
time provided in the AudioTimeStamp of the render callback
occasionally jumps a HUGE number of samples. For example, a render
callback that was anchored at starting sample 195299557 (about 74
minutes since the device started running) suddenly started to get
time stamps like:
inTimeStamp->mSampleTime = 813501609541766
This audio device was running at 44100 hz, so that sample time
corresponds to 584 years of samples. i.e. it's wildly wrong. The
result for my application is that as it tries frantically to catch
up to the current sample timestamp it is pitching all audio and
rendering silence.
What could be causing this and how can I catch it?
Other details:
- kAudioOutputUnitProperty_StartTimestampsAtZero is NOT set to
false--i.e. the AUHAL unit is NOT passing raw device samples
- According to the logs, the devices are not changing sample rates,
changing buffer size, changing stream descriptions, or changing
clock source
Any thoughts much appreciated.
Best,
Chris
_______________________________________________
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