Re: clear description of AudioTimeStamp?
Re: clear description of AudioTimeStamp?
- Subject: Re: clear description of AudioTimeStamp?
- From: Jeff Moore <email@hidden>
- Date: Tue, 22 Apr 2003 12:08:40 -0700
On Tuesday, April 22, 2003, at 11:55 AM, Kurt Bigler wrote:
on 4/22/03 11:24 AM, Jeff Moore <email@hidden> wrote:
On Monday, April 21, 2003, at 11:30 PM, Kurt Bigler wrote:
I am finding that I am getting kAudioDeviceProcessorOverload
nofications
with no gaps in mSampleTime.
Checking for gaps in mSampleTime seemed like the obvious thing to do,
since
I need to know the number of samples skipped in order to
resynchronize
my
buffers.
However, it appears that mHostTime is showing a gap that is at least
approximately correct. So it looks like I am stuck with scaling
mHostTime
in order to determine the number of scamples skipped, which seems
absurd.
This sounds like a manifestation of a bug I found the other day that
caused the HAL to send too many overload notifications under certain
circumstances or an overload notification when what really happened
was
that the driver returned an error from the kernel trap.
Thanks Jeff. Note that it is behaving _like_ an overload, in the
sense that
a callback _was_ skipped. After all, mHostTime had a skip. Would you
have
expected mHostTime to skip but mSampleTime not to skip in the scenario
you
are thinking of?
So how can I zero in on this? Or do I just have to wait for a future
OS
release to find out more about the problem I am seeing?
I would expect that if there was a gap in the host time, there would be
a corresponding gap in the sample time. My admittedly limited testing
this morning after reading your email bore this out. Perhaps there is
another bug in there somewhere.
One thing that I have observed is that occasionally the HAL will issue
a spurious overload within a couple of IO cycles of starting up.
Perhaps this is what you are seeing?
Is mRateScalar by any chance useful for this? This appears to be
another
field of AudioTimeStamp that is undocumented, except for the phrase
"system
rate scalar".
The rate scalar field, which only started getting filled out with
10.2,
indicates the ratio of the actual sample rate to the nominal sample
rate.
Aha, so we really do get some substantial help with on-the-fly sample
rate
conversion if we want to do it. That's great. You (I think it was
you) had
mentioned this in response to a question several months ago, but you
did not
give the details.
The rate scalar the HAL provides comes straight out of it's
interpolation engine that guides the wake ups of the IO thread. You can
glean the same information by low pass filtering the differences in
successive host times passed to your IOProc.
I should also point out that in 10.2 the HAL added a property to get
the actual sample rate for a device.
Do we really have to log a bug to get these things documented, or are
you
also taking notes?
I take notes, but filing bugs never hurts.
--
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.