RE: inOutputTime accuracy?
RE: inOutputTime accuracy?
- Subject: RE: inOutputTime accuracy?
- From: Jim Dolan <email@hidden>
- Date: Fri, 16 Aug 2002 11:48:04 -0400
Jeff -
Thanks for taking the extra time to help me figure this one out...
I think that the internal CoreAudio calculations are relatively correct from
callback to callback. Unfortunately that does not correspond to what I
hear out of the speakers. My guess is that just the initial values may be
wrong. I can show the descrepancy in one of two ways:
1) I loop one audio channel along with the svideo output of a Titanium Power
Book into the audio 1 and 2 inputs of a G4. I record the both signals with
an audio editor on the G4. I can now see the video and audio signals as
audio waveforms. I play a composition with a color bar frame and tone blip
once every second. Video updates are based on the sample position of the
audio and take a negligable amount of time to display. Once the sample
position reaches the point that I think audio is now playing (ie: the
initial offset), I issue the first video callback. The recorded waveforms
on the G4 shows the audio blip occurring 3k samples ahead of the video (you
can also see/hear the offset if you look closely). The sound comes out of
the speaker before I reach the offset.
2) I have a timeline indicator that also updates with the sample position.
I hear the sound before the indicator reaches the audio in the timeline.
This is just a visual test so it is hard to determine exactly how far off
things are, but the audio clearly occurs before the indicator reaches the
audio in the timeline.
Typically I see the initial inOutput.mSampleTime is ~8k. now.mSampleTime in
the first callback is ~4k. Substracting out the 3k samples leaves only 1k
sample positions to perform the callback and start playing the buffer. This
seems kinda short but not unrealistic?
Jimmy D.
-----Original Message-----
From: Jeff Moore [
mailto:email@hidden]
Sent: Friday, August 16, 2002 12:02 AM
To: CoreAudio (E-mail)
Subject: Re: inOutputTime accuracy?
That certainly sounds odd.
I have done tests where I have physically looped the output back to the
input. I can then put a pulse out of the output at a known time and see
where it comes up again in the input. This lets you see how the time
stamps line up with reality. When I do this, the error is no where near
3K samples, and it's definitely never early. I was using the built-in
hardware the last time I ran this test.
Can you tell me a bit more about what hardware you're using and what
system version? Also, can you describe exactly how you are determining
that things are 3K samples early?
On Thursday, August 15, 2002, at 03:18 PM, Jim Dolan wrote:
>
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.
>
>
--
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.