Re: Float64 to unsigned bug shows in mSampleTime
Re: Float64 to unsigned bug shows in mSampleTime
- Subject: Re: Float64 to unsigned bug shows in mSampleTime
- From: email@hidden
- Date: Mon, 26 Aug 2002 06:35:18 -0500 (CDT)
On Sun, 25 Aug 2002, Doug Wyatt wrote:
>
Personally I'd first consider using UInt32's, which are cheaper than
>
64-bit ints:
>
>
- on my first IOProc callback, remember the first mSampleTime I see as
>
a Float64, call it "zeroTime"
>
- on subsequent callbacks, subtract zeroTime from mSampleTime, and
>
store it in a UInt32.
>
>
Time will only go forward :-)
>
>
Note: if you need to run for more than 27 hours at 44.1, or shorter
>
periods at higher sample rates, then you do need more than 32 bits.
>
>
secondsPerHour = 3600.;
>
(pow(2,32) / 44100. / secondsPerHour) = 27.05
>
>
Doug
I already do something similar to your method with timestamps. I used a
Float64 as the holder for the start time and an unsigned for the current
time simply because I hadn't had quite enough data to set my policy
towards timestamps. I'm not so much worried about 27 hours at 44.1kHz as I
am a little worried about 12 hours at 96kHz or 6 at 192kHz, so I think
I'll start to use a UInt64 or SInt64. Thanks for the answer, as now I can
set a standard policy on timestamps in my application.
One other thing - about how often does the system time as retrieved
through AudioConvertHostTimeToNanos() rollover back to 0? If the nanosecond
representation uses the full 64 bits, I think it would only restart around
every 584.94 years but I thought I heard someone say it can reset every
few days since its source value is based on processor cycles instead of
nanoseconds.
-Ben
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.