Re: Input callback timestamp reset and current sample time
Re: Input callback timestamp reset and current sample time
- Subject: Re: Input callback timestamp reset and current sample time
- From: William Stewart <email@hidden>
- Date: Thu, 29 Sep 2005 14:39:31 -0700
I'd agree with Jeff's comments, but would like to add:
On 29/09/2005, at 12:51 PM, email@hidden wrote:
Another thing I noticed is that the timestamp passed to my input
callback is in the future (4100 or so samples, which is close to the
4096 sample buffer I configured) so I have to compensate by adjusting
by a guess of 4096 samples.
Yes - that is correct.
You can't render data for a buffer that starts at "now", because by
the time you are finished rendering it, "now" is no longer "now" -
its in the past.
So, the way CoreAudio works is that an I/O proc fires and gives you 3
time stamps:
(1) Is the time stamp of the input data - if any of course. This will
always be at least a buffer size in the past
(2) Is the time stamp for now - when the I/O proc was woken up to run
(3) Is the time stamp for the output data you will provide. This will
is always some time in the future - usually it is a buffer size in
the future.
(for completeness: there are properties of the device called the
safety offset, and the IOUsage period that contribute to the actual
values of these time stamps and their relationship to now - this is
all deterministic! There is also a presentation latency figure that
describe the time between a driver getting a sample and the time
until it is actually presented/received from/to its I/O)
This is of course what *underlies* the AUHAL output unit - and is the
basic audio I/O service of CoreAudio - the HAL layer.
AUHAL is an audio unit. Its job is two fold:
(1) Simplify the interface to the lower level HAL layers - take care
of alot of the complexity of device state and I/O
(2) Provide an AU interface to the device, so as to provide an easy
and natural fit with the other AUs on the system.
AUHAL therefore represents and abstraction of the device - one of
these is the way it messes with the time stamps of the device. For
instance, AUHAL can also do sample rate conversion, so there can be
more or less samples that AUHAL requests of its provider than the
device will need - so it manages the translation of the sample count
field of the time stamp. What AUHAL does do as well, is to provide
the Host Time value for the output time that it is asking you to
provide data for. This allows its clients to know something about the
device time that corresponds to this particular request for audio
data... As Jeff has described, once you have that host time, you can
get a sample time on the device - but really (as I tried to say
earlier) - I'm not at all sure that this has any real meaning for you.
I think we have all of the information that you need; you just need
to understand some of the timing semantics of the system to know how
to get/interpret/etc the data that is available.
Bill
A suggestion for the future would be an API or property to get the
current timestamp for the audio unit (in sync with what will be passed
to the input callback). This should provide a reliable way to get the
current sample index that is in sync with the audio unit and insulated
from any underlying device changes. For example, with USB audio, you
can always look at the frame number to know where you're at in the
playback so it's relatively easy to correlate timelines.
_______________________________________________
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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