Re: inOutputTime accuracy?
Re: inOutputTime accuracy?
- Subject: Re: inOutputTime accuracy?
- From: Jeff Moore <email@hidden>
- Date: Fri, 16 Aug 2002 11:29:46 -0700
You didn't answer my questions about the hardware you are using and
what system. The driver and hardware involved here is absolutely
critical to know. If you can't discuss the hardware in the clear,
please email me privately. I would like to understand what you are
running into.
My current suspicions are that the hardware you are using isn't
reporting the right time stamps or you are running in to some
inaccuracies in the HAL's math that were alleviated somewhat in Jaguar.
I'm leaning toward the former because none of the errors in the HAL's
math in 10.1.x and earlier were anywhere near the size you are seeing.
On Friday, August 16, 2002, at 08:48 AM, Jim Dolan wrote:
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.
--
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.