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: Sat, 24 Aug 2002 02:40:47 -0500 (CDT)
I realized that this behavior was probably not incorrect, simply an
initially inconvenient change and I thought perhaps others might run into
it. Using a UInt64 or SInt64 instead of an unsigned type makes no
difference as far as the problem with mSampleTime. After running the
debugger I see that the mSampleTime difference is smaller than the
accurate sample time difference on an order of 1^-12 or 1^-13. My guess is
the old gcc would round this when converting to an int whereas the new one
simply cuts it off, which is more consistent behavior (although it would
be nice if printf reflected this change).
A related question - is there any reason for me to leave the
mSampleTime field as a Float64? I mean, is the fractional part of the
mSampleTime field of any value to me as a user of Apple APIs which supply
me with AudioTimeStamps or would I be just as well off to replace it with
SInt64s by wrapping around any occurrences of AudioTimeStamps?
Thanks,
Ben
On Fri, 23 Aug 2002, Jeff Moore wrote:
>
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.
_______________________________________________
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.