Re: Sample Rate: 44100 or 48000
Re: Sample Rate: 44100 or 48000
- Subject: Re: Sample Rate: 44100 or 48000
- From: Jeff Moore <email@hidden>
- Date: Mon, 15 Aug 2005 12:05:28 -0700
On Aug 14, 2005, at 10:10 AM, Marc Van Olmen wrote:
On Aug 14, 2005, at 11:23 AM, Marc Van Olmen wrote:
to answer this part of the question my self found some sample code
and created this:
typedef double OS_TimeValue;
AudioTimeStamp theCurrentTime;
OSStatus anError;
theCurrentTime.mHostTime = 0;
theCurrentTime.mRateScalar = 0;
theCurrentTime.mReserved = 0;
theCurrentTime.mSampleTime = 0;
//theCurrentTime.mSMPTETime = 0;
theCurrentTime.mWordClockTime = 0;
theCurrentTime.mFlags = kAudioTimeStampSampleTimeValid |
kAudioTimeStampHostTimeValid;
anError = AudioDeviceGetCurrentTime(fOSMovie-
>fAudioClockDeviceID, &theCurrentTime);
pDeviceClock->setTime((OS_TimeValue)
AudioConvertHostTimeToNanos
(theCurrentTime.mHostTime),kOS_TimeToNanoSeconds);
I'm wondering this code is not wrong?
This is the proper code for getting the current time of the given
hardware device. This particular request will get you the sample time
and the host time that correspond to the same point on the device's
time line.
shouldn't I add "AudioDeviceTranslateTime"?????
For what purpose? AudioDeviceTranslateTime is there to allow you to
ask the device given the sample time, X, what is the corresponding
host time or vice versa.
I'm wondering if the 'AudioConvertHostTimeToNanos' works only
in the macOS x hardware clock??? and not from my device???? because
how does it now the clock frequency of the device?? maybe this is
stored inside the mHostTime value???
Wow. You have some very large misconceptions about how time
functions and is represented in the system. You _really_ should go
back through the various discussions of time on this list and go over
my various presentations at WWDC about how this stuff works. Here's a
short paragraph that will hopefully start you back on the right path:
Time in CoreAudio is represented by an AudioTimeStamp structure whose
fields all describe the same point in the device's timeline using
different units. Thus, AudioDeviceGetCurrentTime() is providing you
the current time of the device. The flags you set in the
AudioTimeStamp struct indicate which representations of the current
time you want to get.
Finally, the API in <CoreAudio/HostTime.h> is there to facilitate
access to the CPU's most accurate time base (the one exported by the
kernel in <mach/mach_time.h>). It really has no bearing on anything
you are doing, unless you want to convert between the CPU clock
(which is proportional to the CPU bus usually) and nanoseconds. If
you do, this is a good way to do it. You could also do it yourself or
use the CAHostTimeBase class in our SDK to wrap it up as well.
I just doubt it a little bit?
So maybe this is then more Correct?????
typedef float64 OS_TimeValue;
AudioTimeStamp theCurrentDeviceTime;
AudioTimeStamp theCurrentTimeInMacOSXHardware;
OSStatus anError;
theCurrentDeviceTime.mHostTime = 0;
theCurrentDeviceTime.mRateScalar = 0;
theCurrentDeviceTime.mReserved = 0;
theCurrentDeviceTime.mSampleTime = 0;
//theCurrentTime.mSMPTETime = 0;
theCurrentDeviceTime.mWordClockTime = 0;
theCurrentDeviceTime.mFlags =
kAudioTimeStampSampleTimeValid | kAudioTimeStampHostTimeValid;
anError = AudioDeviceGetCurrentTime(fOSMovie-
>fAudioClockDeviceID, & theCurrentDeviceTime);
FW_FAIL(anError);
This is fine so far. You get the current time in both samples and
host ticks.
anError = AudioDeviceTranslateTime(fOSMovie-
>fAudioClockDeviceID, & theCurrentDeviceTime, &
theCurrentTimeInMacOSXHardware);
FW_FAIL(anError);
This gets you nothing since both the sample time and the host time
are already filled out properly from the previous call to get the
current time.
// Time can now be converted to my NanoSeconds precisions
clock
pDeviceClock->setTime((OS_TimeValue)
AudioConvertHostTimeToNanos
(theCurrentTimeInMacOSXHardware.mHostTime),kOS_TimeToNanoSeconds);
If you are dealing with things in terms of nanoseconds, this is fine.
However, you are throwing away precision if the CPU clock is at a
higher rate than 1GHz, not to mention the rounding error in the
conversion to nanoseconds. Plus, most system routines for scheduling
threads and what not deal with the CPU clock in it's native base
anyway. This is why in my own code I prefer to keep the time in the
native units and only convert it to something "human readable" when I
need to display it, like in a printf or whatever.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden