The display doesn't really need to be that accurate, and you can
catch every major audio application on the market showing slight
variations in display performance, so I wouldn't let that bother
you. You can use CoreAudio to determine the output device latency so
that you can predict the amount of time it takes between delivering
the start of your audio file and when someone will hear it, so that
will help accuracy.
Tahome beat me to answering your question about audio accuracy. The
key is that you're always delivering audio, including the silence
between the sounds, so you have precise sample-accuracy at all times.
On Dec 22, 2008, at 00:51, Maissam Barkeshli wrote:
I'm still a little bit confused though about how this specifically
should work. Say I want to do something simple: play a single audio
file once per second and simultaneously update a visual counter on
Right now I'm looking at starting a CoreAudioClock, running a loop
and continuously polling the clock to see whether a second has passed
since the last time. Once at least one second has passed, then play
the file and update the display. The problem with this is that even
though CoreAudioClock is very accurate, the program itself sometimes
might actually take an extra fraction of a second if the computer is
busy with other applications.
But people still develop rock-solid metronome applications, with
displays and everything. How do they do it? The only thing I can
think of about making this work is that somehow I need to be using a
thread that has extremely high priority, so that the operating system
focuses on this particular program.
Perhaps I have settle with not being able to get the display to be
perfectly accurate, but with your suggestion I can get the audio to
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