What can cause an AUHAL sample timestamp to jump far into the future?
What can cause an AUHAL sample timestamp to jump far into the future?
- Subject: What can cause an AUHAL sample timestamp to jump far into the future?
- From: Christopher Ashworth <email@hidden>
- Date: Mon, 16 Mar 2009 12:34:44 -0400
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
- The reports so far come from customers using the following devices:
- 2 reports from an M-Audio ProFire Lightbridge
- 1 report from a Presonus Fire Studio Lightpipe
Is there something unique about lightpipe devices in CoreAudio?
- I have NOT yet been able to reproduce this behavior on the devices I
have, which include: built-in audio, Edirol FA-66, MOTU UltraLite
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