Re: clear description of AudioTimeStamp?
Re: clear description of AudioTimeStamp?
- Subject: Re: clear description of AudioTimeStamp?
- From: Kurt Bigler <email@hidden>
- Date: Tue, 22 Apr 2003 12:57:59 -0700
on 4/22/03 12:08 PM, Jeff Moore <email@hidden> wrote:
>
On Tuesday, April 22, 2003, at 11:55 AM, Kurt Bigler wrote:
>
>
> on 4/22/03 11:24 AM, Jeff Moore <email@hidden> wrote:
>
>
>
>> 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?
I do see that also.
But no, this happens later. It _is_ spurious in the sense that there is not
much going on. That is, the render callback is only running at a small
fraction of full load, yet this still happens every now and then. I have no
other real-time threads of my own that would get in the way, and for that
matter this happens when my feeders are completely unloaded. There is
still a slight load in the render callback because my current implementation
does some effects there. However, I do have 3 audio engines running, on 2
cpus. The interface is firewire-based.
I had not yet questioned _why_ the overload was happening, because for the
moment I was glad it was happening so I could exercise my overload recovery
logic. I usually have to wait less than a couple of minutes, but it also
_seems_ like a recent reboot (even a couple minutes ago) helps!
It seems to me that it would be good if there were some way to get a more
extended error status. A special function that can be called from a
callback might be part of this picture. Without more status available to
me, you might have to have my hardware and host software on order to
diagnose this. Is there a debug build of coreaudio that might be available
through the seed program?
There is of course some possibility that my code is doing something that I
think it is not doing. I have not been anal, but I have not been sloppy
either. (But maybe there is nothing in-between.-)
>
>>> 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.
Yes, I just always wondered what amount of low-pass to use, or whether I
could get away with cycle-by-cycle corrections (withoug lopass). But
presumably this number is based on some good choices that therefore I don't
have to make myself.
>
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.
Done. (Soon.)
Thanks,
Kurt Bigler
_______________________________________________
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.