Re: When is sample number zero ?
Re: When is sample number zero ?
- Subject: Re: When is sample number zero ?
- From: Jeff Moore <email@hidden>
- Date: Wed, 07 Nov 2001 11:30:40 -0800
on 11/6/01 8:21 PM, James McCartney <email@hidden> wrote:
>
on 11/6/01 2:34 PM, Jeff Moore at email@hidden wrote:
>
>
> I'm just saying that you shouldn't count on the actual values themselves in
>
> any absolute way. Use the distances between them for measuring stuff.
>
>
If it is not something to worry about then that is OK. It helps to know what
>
is going on.
I wouldn't let the fact that you never see 0, worry you.
>
Back when every card had its own API, most gave you some way to
>
prefill the buffer for time zero before starting. CoreAudio goes the other
>
way and doesn't even let you begin until things are already rolling. So that
>
makes one want to know why. I'm satisfied for now.
I agree that such a facility is a good one to have. I spent some time early
during the 10.1 cycle investigating ways in which the HAL could use the
IOProc mechanism to "pre-fetch" the first buffer of output data so it could
be played while waiting for the first buffer of input data to fully arrive.
It was failing at the time for a variety of reasons and was put on the back
burner to revisit at some point in the future.
>
Also related to time:
>
For my application I need to relate core audio time to gettimeofday time.
>
The only way I know how to do this is to bracket gettimeofday() between
>
AudioGetCurrentHostTime() calls for some number of iterations choosing the
>
smallest interval and then just fudge that gettimeofday() (which happens to
>
be a relatively slow call) occurred halfway in between. From that I can
>
calculate an offset to host time.
>
If there is a better way, I'd like to know it.
Hmm. That sounds like a pretty reasonable way. Be careful of thread
pre-emption in your routine that synchs the two clocks.
If you are doing this in a normal time share thread, you will go CPU bound
and your priority will degrade and your code will end up appearing to run
very slowly if it takes long enough to do its job. You might want to
momentarily elevate the priority of your thread to that of a time constraint
thread to assure that your code runs without pre-emption. You might also
want to put the thread to sleep before and after making the synch
calculation to assure that the scheduler doesn't punish you.
I've run into this very problem doing code profiling.
--
Jeff Moore
Core Audio
Apple