Re: inOutputTime accuracy?
Re: inOutputTime accuracy?
- Subject: Re: inOutputTime accuracy?
- From: Jeff Moore <email@hidden>
- Date: Thu, 15 Aug 2002 14:04:25 -0700
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.