On Thu, Jun 16, 2005 at 10:57:51PM +0200, Florian Schmidt wrote:
Ah, i remembered slightly incorrectly. Thanks Paul,
for setting me
straight in #ardour. The thing is that the DLL based client thread
wakeup has the ever so slight possibility to do its thing too early.
Thus coreaudio waits a bit more (the "safety offset").
It seems this safety offset is driver specific but usually ranges from
64 to 32 frames (i have no definite source for this, just a bit of
googling). And with a sufficiently low period size used this accounts
for pretty much an extra period of latency..
Strange... If you would program a timer using the info available from
jackd's DLL, it would never generate its interrupt before the HW is
ready (i.e. has at least a period available). It would actually trigger
just after the interrupt it is derived from (the small average latency
that is not compensated). So I wonder what problem CoreAudio has with
this.
--
FA