Re: driver strangeness
Re: driver strangeness
- Subject: Re: driver strangeness
- From: Jeff Moore <email@hidden>
- Date: Fri, 10 Mar 2006 13:01:15 -0800
That stands to reason. There isn't a whole lot you can learn by just
looking at them short of seeing very obvious issues (which usually
lead to other problems, like overloads too). I have to do various
kinds of statistical analysis on time stamps in order to see
problems. This means I syphon them off and load them into a spread
sheet and start banging on them.
There are two common mistakes I have seen driver writers make with
time stamps. First, the time stamps aren't truly reflecting what the
hardware is doing. This is the hardest problem to resolve since it
requires instrumenting not only the driver, but the actual device,
the USB bus and the controller as well (make friends with USB Prober).
The other problem was the bad first time stamp problem I mentioned.
Usually, it comes about in the following form (in pidgin code):
void MyIOAudioEngine::StartMyHardware()
{
takeTimeStamp();
StartMyDMA();
}
I have seen this kind of code in many drivers. The problem here is
that this first time stamp the HAL sees has nothing to do with the
hardware. It is completely arbitrary and will have the offset problem
I was describing.
IMHO, the fact that you say this only afflicts slower hardware
implies very strongly that you have a time stamp problem somewhere.
There really aren't any easy ways to fix this. You have to roll up
your sleeves and get your hands dirty and dig into what's going on
with the hardware, with the USB bus, and how your driver is
reflecting that out to the HAL.
On Mar 10, 2006, at 12:34 PM, david tay wrote:
What exactly should one be looking for?
The output from the macs that have problems doesn't seem to be
different from those that don't, at least to me.
David
Message: 2
Date: Thu, 9 Mar 2006 15:22:33 -0800
From: Jeff Moore <email@hidden>
Subject: Re: driver strangeness
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Did you look at the time stamps the driver produced with HALLab (they
are shown in the last column of the telemetry)? The reason I mention
this is that it is these time stamps that keep the HAL on track so as
to be able to read the correct data from the ring buffer for any
given cycle and not violate the safety offset.
Another thing to look at is the quality of the first time stamp the
driver lays down. This time stamp needs to be the most accurate you
can make it as the HAL uses it as the anchor point for IO. If it is
offset one way or the other, all the HAL's subsequent reads will be
offset by the same amount. This can lead the HAL to violate the
safety offset. For just this reason, it is a good idea for some
drivers to just eat the first time stamp and only show the HAL the
time stamps starting with the second one.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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