I'm investigating how to programmatically calculate the full latency from output wired back to input. To test I've setup a bi-directional AUHAL with the callback generating a test tone and recording input to show in a basic waveform display so the sample position of where the test tone starts can be seen visually.
We do similar testing although we have automated the process somewhat. The lynchpin of this is AUPulseDetector which you can find in our SDK in /Developer/Examples/CoreAudio/AudioUnits/DiagnosticAUs.
From the documentation and posts from this list the latency for each path is (device latency + callback buffer frame size + device safety offset + stream latency). I gather that the devices kAudioDevicePropertyIOCycleUsage parameter can reduce the latency but this for all tests was left at 1.0
This is basically correct for one way latency.
My first tests looked promising - for my built in input and output this formula gave 1656 samples, and a series of physical tests resulted in latencies between 1651 and 1659 - accurate to +/-5 samples!
What Mac are you testing? Intel macs have separate input and output device normally, so you'd need to correlate the input to the output from separate IOProcs. Depending on how you do that, I could see small errors entering in.
At any rate, the last time I looked at the throughput latency figures, our built-in hardware generally was dead on sample accurate in it's reported vs. measured figures. So the deviations you are measuring could be due to issues with how you are doing the measuring.
Then I tested with a M-Audio Firewire 410 which gave a calculated latency of 1362 (584 for input + 778 for output) but repeated tests showed latencies from 1251 to 1259, again a variation of 10 samples but 100 samples off the money.
While the same issues the built-in hardware raised apply here, there is the added complication of a bug in the our FireWire Audio driver where it would not produce consistent throughput latency figures from test run to test run. This bug has been fixed in Leopard.
What I would appreciate knowing is should I be worried about this? I'm not sure if there is flaws in my method (very possible!) or if it's a case of not all device drivers can get it as good as Apple.