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: <email@hidden>
- Date: Thu, 29 Sep 2005 18:04:25 -0700
> Just curious, but why are you not acting on the discontinuities in
> the time line, such as when headphones are plugged in? The whole
> reason that you see these is to let you know that samples were
> dropped. I'd imagine that knowing this would be very important in
> implementing synch so that you can skip media or whatever you need to
> do in order to maintain synch.
I'm going in the other direction: playing samples based on an absolute
reference time. So if CoreAudio has to drop samples due to a device
reset, it's okay, but I still need to know where the sample count
would have been had it not dropped those samples. For example, with a
USB audio device, even it has to drop samples, I can still look at the
current frame number (which keeps on advancing) to know how much it
would have played so I know the correct frame number to insert the
next chunk of audio.
> most quality engines I've run into don't
> really care too about the exact values of the time stamps. Just
> keeping track of how much has been played so far and how much is
> needed to generate in the next cycle is usually enough to do just
> about anything.
The exact values of the time stamps aren't important to me, but I need
the relative values between time stamps because I need to know how far
the sample time would have advanced. Even discontinuities in the
timeline are okay, but I need to know exactly when they occur in a
serialized manner so I can re-calculate my mapping between CoreAudio's
time and absolute time without a race condition between the periodic
time mapping update and the input callback. For example, if my
periodic mapping update occurs immediately before a device reset then
the input callback is called with the new timeline, my
CoreAudio->Absolute mapping will be stale until the next periodic
mapping update. If I knew the timeline would change immediately after
it changed, but before the next input callback was invoked, I could
fix my mapping and things would be okay.
_______________________________________________
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