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: Herbie Robinson <email@hidden>
- Date: Sat, 24 Aug 2002 04:19:01 -0400
Actually, I believe that C defines that operation to truncate.
Sounds like the new compiler is correct and the old one was wrong.
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.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.