On Fri, May 13, 2005 at 07:33:18PM +0200, Florian Schmidt wrote:
> > During the process callback the client can call
> > jack_last_frame_time() which gives it the framecount of the first frame
> > in the current period.
> actually i'm not 100% sure on the semantics of jack_last_frame_time. It
> might also be the framecount after the last process cycle.. Hmm, is that
> equivalent? /me wrenches his brain
If you look at the current implementation, it just _is_ the frame count.
What could happen (and could be confusing but need not be), is that if
you call jack_frame_time() very early in the process cycle, it could
give you a value that is just _before_ the frame count. There is nothing
special about this, it happens when the current engine wakeup is faster
than average. The DLL removes the jitter, but can not compensate for
the average interrupt to wakeup delay.
> Anyways, i know for sure that it can be used to put frames in the
> process cycle in relation to frame_time() and thus above holds modulo an
equal to the average wakeup delay. It should be very small on any system
tuned for audio use. The exception is USB.
yeah :) My remaining silent to this paper when you posted it the first
time around is due to me agreeing with it.
> Please ignore the proposal part in this doc - it is being reworked (*).
> > When on its signal path there are
> > additional clients which introduce latencies, these just have to be
> > added to this..
> Yep. The problem is to find out if there are any. It looks simple in
> simple cases, but once you have a client in the path that has some
> direct connections to the soundcard and some that go through other
> clients, it is not possible to do this without knowing that client's
> internal routing and delays.
Agreed. And for that we need a new API [like mentioned in the other