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: Jeff Moore <email@hidden>
- Date: Fri, 23 Aug 2002 11:44:30 -0700
Ccasting a 64 bit floating point number to a 32 bit unsigned integer is
a lossy conversion. As such, I believe that any rounding/truncation
that needs to go on to accomplish the task is undefined by the language
standard and is at the whims of the compiler and/or CPU as to how best
to accomplish it. By taking different casting paths, you are probably
causing different rounding/truncation to happen. The change from GCC2
to GCC3 is probably the thing that caused this to change somewhat, but
I'm pretty sure it all still complies with the relevant standards.
A UInt32 isn't big enough to hold the range of a Float64 anyway. You'd
be better off using a SInt64 if you have to convert it to an integer.
On Friday, August 23, 2002, at 03:24 AM, email@hidden wrote:
I recently purchased a new dual 867 PowerMac and installed the new
developer's tools on it. I tried running my project and everything
worked
fine except that at some point the mSampleTime field didn't look
proper.
I store the the first mSampleTime as the basis for when I receive
subsequent sample times and the difference would occasionally show up
to
be 1 sample less than expected - usually within the first ten
callbacks.
It seems that the code
curSampleTime =
(unsigned)(inOutputtime->mSampleTime-initialSampleTime);
can cast erroneously under Jaguar. I think it is erroneous for three
reasons:
First, it worked fine previously. Second, when I printf() the value
(inOutputtime->mSampleTime-initialSampleTime) as a long float, it shows
the value to be correct but the cast unsigned value can still be 1 less
than it should. Third, if I change the aforementioned code to
curSampleTime =
(unsigned)(float)(inOutputtime->mSampleTime-initialSampleTime);
it always casts correctly. Therefore it seems that Float64 to float
works and float to unsigned works but Float64 to unsigned can fail. As
this is such a limited case and creating sample code would require a
large amount of time, I haven't submitted a bug report. I thought it
might
be a good idea to post this here in case anyone else hit the same
problem
or if someone else has isolated the problem better than I have. The
problem occurred when recording either with the built-in audio
controller
or with a Tascam 224. After I found the work around casting I stopped
investigating (for now) so the depth of my knowledge about the problem
is
limited to pretty much what I've already written.
-Ben
p.s. When can we start discussing API changes in the most recent
developer's tools? I haven't heard that it's public yet.
_______________________________________________
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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.