Re: Best approach for a clock source
Re: Best approach for a clock source
- Subject: Re: Best approach for a clock source
- From: Brian Willoughby <email@hidden>
- Date: Tue, 26 Jan 2010 19:27:36 -0800
On Jan 26, 2010, at 06:14, daniel medina wrote:
I initially opted for an independent timer becouse i needed to
determine the timestamp of a real time input event (i.e., somebody
playing a note). The core audio callback is called at a constant
rate, in the case of remoteIO the buffer size is typically 1024
samples, that is 23 ms. If i use the core audio timeline this would
be the maximum precision to determine the timestamp of a realtime
input event. Or that is what I thought...
With your approach, maybe the right thing to do would be to store
the host time at the start of each core audio callback, and then
calculate the real time event timestamp using the host time of the
received event, the host time of the callback and the callback
timestamp. Is the calling-time of the core audio callback the
correct reference to do this?
I believe so. You can convert between host time and CoreAudio time.
Look in the CoreAudio headers for the appropriate API. You should be
able to achieve finer precision than 23 ms using those time
references outside of the callback, then position your audio within
the callback at the correct sample offsets based upon the time stamp
that CoreAudio gives for the buffer in the function parameters.
Brian Willoughby
Sound Consulting
_______________________________________________
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