Re: Input callback timestamp reset and current sample time
Re: Input callback timestamp reset and current sample time
- Subject: Re: Input callback timestamp reset and current sample time
- From: Jeff Moore <email@hidden>
- Date: Fri, 30 Sep 2005 12:03:54 -0700
Given that plus what you've said previously, it is clear that you are
not correlating the three clocks involved in the operation, namely
the wall clock, the sample clock and the CPU clock, so that you can
do the proper rate conversion for the operation you are describing.
So, all you are really doing is triggering something (playback of a
buffer of samples) in response to a stimulus (a specific wall clock
time). This is fundamentally no different than what a software synth
does with MIDI key downs or how a game handles sound effects with
OpenAL.
All you really need is a timer thread that watches the wall clock and
queues up the buffers for the sound engine to play in it's next
cycle. All the sound engine does is play what's in the queue. If the
queue is empty, it plays silence. If all you're doing is playing
samples at 44100 (which has samples roughly 22.6 mics apart)
contiguously, all you have to do is put them in one big buffer and
queue them from the timer thread when the start time comes about.
At most, you'll be counting the samples you've played so that you can
schedule buffers to start at an offset into an IO cycle to achieve a
higher degree of synch. But however you do it, by and large, you
don't have to know anything about the time stamps.
On Sep 29, 2005, at 7:19 PM, email@hidden wrote:
Everything you say below says to me that you don't need to do any of
this time translation stuff. You don't even need to ask about the
current time at all. It is just overkill for just playing back a
stream of data without regard to anything else.
Sorry if my reply was confusing, but I do need to sync playback to an
external source. I essentially need to say "At exactly 5 PM UTC, play
sample 1", at 5 PM and 22.6 microseconds, play sample 2, etc., but as
a continuous stream of audio without little gaps due to rounding and
timing granularity errors since 1 sample isn't exactly 22.6
microseconds. This is why I'm creating a mapping between this absolute
timeline and the sample clock timeline of CoreAudio. This all works
pretty well until the audio device resets.
I looked at AUScheduledSoundPlayer, but it appears to require 10.4 or
later. I need to run on earlier systems.
--
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