RE: inOutputTime accuracy?
RE: inOutputTime accuracy?
- Subject: RE: inOutputTime accuracy?
- From: Jim Dolan <email@hidden>
- Date: Thu, 15 Aug 2002 18:18:55 -0400
Jeff -
I am not calculating the time, I am counting the sample positions as
reported by the devices in the IOProcs and AudioDeviceGetCurrentTime. I am
hearing the audio out of the speakers upto 3k samples BEFORE the output
device now.mSampleTime reaches the first IOProc's inOutput.mSampleTime. The
rate at which the hardware is running (actual vs. nominal) should be
irrelevant to the sample count of the device at any given time. The initial
inOutput.mSampleTime is approximately 3k samples later than what I hear
through the speakers, and I havn't even added in the
kAudioDevicePropertyLatency yet!
Thanks again...
Jimmy D.
-----Original Message-----
From: Jeff Moore [
mailto:email@hidden]
Sent: Thursday, August 15, 2002 5:04 PM
To: CoreAudio (E-mail)
Subject: Re: inOutputTime accuracy?
On Thursday, August 15, 2002, at 12:55 PM, Jim Dolan wrote:
>
Hi Jeff -
>
>
I am a little confused - The inOutputTime.mSampleTime should
>
increment by the sample frame size every cycle.
True.
>
It won't matter how long I wait to take an anchor, because the sample
>
time always increases with this regularity.
Yes, the sample time will increment by the buffer size unless there is
an overload, in which case there will be discontinuities.
Of course, this is just the sample time. You also have to be cognizant
of what is going on with the host time as well because you can't just
assume that the hardware is running at the nominal rate. The succeeding
host time differences will reflect the actual sample rate over time.
This has to be a factor when synching different time bases.
This whole actual vs. nominal sample rate thing is at the crux of why
you want to run the hardware a bit prior to taking an anchor. You want
to give the HAL a chance to lock on to the real sample rate of the
device in order to achieve good solid synch.
>
If this is not the case won't we wind up with gaps or overlaps? What
>
you are saying is that the latency is dependant on the driver and the
>
hardware.
Very much so.
>
How can I ever be able to determine exactly when the first sample
>
will be played if I support multiple devices or systems?
The driver reports it's latency figure in kAudioDevicePropertyLatency.
You should add this value to the output time stamp to determine when
the data is going to hit the wire. But, you should also be making use
of the host time to make sure things are mapping where you think they
are.
>
Jimmy D
>
>
-----Original Message-----
>
From: Jeff Moore [mailto:email@hidden]
>
Sent: Thursday, August 15, 2002 3:37 PM
>
To: CoreAudio (E-mail)
>
Subject: Re: inOutputTime accuracy?
>
>
>
You need to account for the latency of the hardware too. The output
>
time stamp passed in to your IOProc reflects the driver's safety
>
offset, but not the latency in the hardware.
>
>
One other thing I would do is to start the hardware and let it run for
>
a few cycles before taking your anchor point. The math in the HAL
>
really needs 2 time stamps from the driver before it can be locked on
>
to the true sample rate of the hardware. This makes the first go around
>
somewhat inaccurate by the difference between the nominal and the
>
actual sample rates.
>
>
On Thursday, August 15, 2002, at 07:08 AM, Jim Dolan wrote:
>
>
> Hi -
>
>
>
> My application needs to keep track of the sample position as it is
>
> playing.
>
> During the first output IOProc I take inOutputTime.mSampleTime and
>
use
>
> that
>
> as an initialOffsetTime to the first sample that will be played.
>
> Later when
>
> I check for the sample position I ask the device for the current time
>
> and if
>
> the current time has passed the initialOffsetTime I know that we are
>
> now
>
> playing samples and can start incrementing the composition sample
>
> position.
>
> The sample position is roughly the currentTime - initialOffsetTime.
>
> This
>
> seems to work fine except that I do not think that the original
>
> inOutputTime.mSampleTime is accurate. I am trying to sync audio to
>
> video
>
> and I notice that I need to substract 3k samples from that initial
>
> offset to
>
> get them to line up. As though the first sample is being played
>
> earlier than
>
> I was told in the IOProc. Once we begin, the relative accuracy from
>
> IOProc
>
> to IOProc is very good, but the start time seems wrong. I am using a
>
> 4096
>
> sample frame size.
>
>
>
> Is there a bug here or is there something that I am still not
>
> accounting
>
> for?
>
>
>
>
>
> Thanks for your help...
>
>
>
> Jimmy D.
>
> _______________________________________________
>
> 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.
>
>
--
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.