Re: When is sample number zero ?
Re: When is sample number zero ?
- Subject: Re: When is sample number zero ?
- From: Jeff Moore <email@hidden>
- Date: Tue, 06 Nov 2001 12:34:19 -0800
on 11/5/01 8:19 PM, James McCartney <email@hidden> wrote:
>
So why does my appioproc not get a crack at putting out that sample number
>
zero? Apparently a number of zeroes are coming out first?
Mostly because the HAL starts it's counter at something greater than 0 since
that makes it's internal math work out much better. It's an arbitrary
number. It could easily pick 357821 without making any difference to how
things work. Just so happens the number it uses makes it's math a bit more
efficient.
This number is _not_ the sample count register on the card. It is derived
from the number of times the driver has looped through it's ring buffer and
the size of that ring buffer.
Further, the "0" time is going to be occupied by things like thread
scheduling latency and other initialization things that happen when the
hardware and the IOThread are first started up. By the time the HAL is in a
state where it can begin doing IO, 0 has come and gone.
On top of that, the HAL always takes a sleep period when the IOThread starts
up to account for the initialization time and to let the input data (if the
device has input) come in for delivery.
The time between your call to AudioDeviceStart() and when your IOProc gets
called the first time is not guaranteed and should not be depended on. If
you want low latency output, you should have long since started the hardware
by the time you want to output data.
>
If I am word clocked to a hard disk recorder, do I have some control over
>
that first output sample?
At this point in the game, you don't have any absolute control of the sample
stream going out. Some kind of control protocol to facilitate this sort of
thing is a desirable future direction.
>
Mostly it just seems weird that I do not get to see sample zero, but instead
>
it acts like "we now join our program already in progress" (at some random
>
location). You always feel like you missed something important..
That's because the stack is designed to be shared amongst many clients. It
is quite often the case that you have joined in the middle of something.
This is one of the reasons why you should not depend on the actual value of
the time stamp, but rather distances between them.
on 11/6/01 3:12 AM, andybull <email@hidden> wrote:
>
Jeff, are you saying that the sample time is unreliable (because it can
>
wrap) and that we should use it merely to grab an anchor (at start time) and
>
offset the anchor (during run time) using the difference each time we see it
>
?
Not at all. The sample times the HAL gives you are very reliable and
self-consistent.
I'm just saying that you shouldn't count on the actual values themselves in
any absolute way. Use the distances between them for measuring stuff.
This is what I meant by picking anchor times and using offsets from the
anchor. It's basically how you could implement some kind of scheduled audio
playback using the time stamps the HAL provides as the basis.
--
Jeff Moore
Core Audio
Apple