Hi Ralf, We are very interested in fixing timing problems of this nature. I agree they are absolutely critical for musicians.
> I looked at the recording done with Qtractor by Audacity. It's 4 to the > floor, with one beat 'pre-recorded' at 120 BPM. > > Should be / is > = 500.000 ms/ ~ 502.400 ms > = 1000.000 ms/ ~ 1002.450 ms > = 1500.000 ms/ ~ 1502.425 ms > = 2000.000 ms/ ~ 2001.400 ms > = 2500.000 ms/ ~ 2501.450 ms > = 3000.000 ms/ ~ 3001.500 ms > = 3500.000 ms/ ~ 3501.725 ms > = 4000.000 ms/ ~ 4001.500 ms > > max. delay + 2.45 ms ~ 1/2 Buffer > min. delay + 1.40 ms ~ 1/4 Buffer > no negative delay > > In other words > constant delay + 1.40 ms ~ 1/4 Buffer > and max jitter + 1.05 ms ~ 1/5 Buffer Thanks for this detailed analysis :-) Please report your findings to the Qtractor project in the first instance. I found a similar problem when using Hydrogen with Ardour and JACK transport - the Ardour bar lines don't match up with the Hydrogen beats when you zoom in very closely. However I think that was different problem, because the delay was negative. There is a work-around for this bug now in the Hydrogen development tree. > Any thing I can do to fix it? I've got one idea myself, it should be > possible to reduce the latency by decreasing the Frames, what will cause > less time/buffer. You can reduce the effect that way, but when recording a JACK client into another JACK client there really shouldn't be any timing differences at all, however small. Cheers! Daniel _______________________________________________ 64studio-devel mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-devel
