I’m running latest 2.8 with jackd 0.116.1 on Ubuntu Jaunty. I’m using a Dell D420 laptop with an RME Multiface.
On large sessions I regularly encounter a problem where, after changing a track’s output to feed a bus, tracks will go out of sync with each other. Restarting the session fixes the problem.
It is hard to reproduce on sessions with small numbers of tracks.
The person that looked at the bug couldn’t reproduce the problem.
I’ve since noticed that on big sessions (over 100 tracks) there are other things that can trigger the situation - starting another jack client (such as jkmeter), or even something as trivial as muting a track! It’s turning into a bit of a showstopper for me as the sessions I’m working on take several minutes to load and I’m having to do this once or twice an hour
So… is there anyone else out there seeing anything like this?
You are likely running against the limitations of latency correction in Ardour, namely IIRC busses do not handle latency correction for various reasons. Just tracks. I believe Paul will be along to correct me if my memory is failing again(Been known to happen on occasion;)
I’m experiecing the same behaviour with as little as 4 or 6 tracks loaded, some plugins (very little - about 25%cpu usage), no external programs connected (excepted jack of course): offset when changing routes (on the track which route has been changed).
If I do multiple changes, the offset add to each other, possibly resulting in quite a big one.
Stopping and starting transport again corrects this offset for me.
I didn’t notice this until recently, after my old digital mixer broke down, and due to my very limited budged I will most likely be forced to do mixing in the box for quite some time. So I loaded an old project for testing how ITB mixing works for me…
On this occasion I tried some new things like parallel compression wich involves sending the signal to multiple busses. First I thought it’s the way that Seablade mentioned, but on reloading the project the offset between the tracks was gone. So I think that latency correction is handeled on busses as well.
Changing the routing resulted in latency issues again. Stopping and restarting the transport doesn’t do the job here - I need to reload the session to get rid of the offset.
@seegwen: I think that’s a different (although possibly related) issue as restarting the transport doesn’t fix it for me
@the C.L.A.: thanks, I’m glad I’m not alone in this!
@seablade: I’ve already sponsored that bug and I’ll increase the amount if there is some work necessary to fix this… I’d rather spend the money on ardour than on moving to another DAW!
So is latency compensation for buses going to be implemented? As you may have noticed from the gearslutz thread this is a pretty fundamental feature for serious bus usage… is it worth starting an “implement latency compensation for buses” bug to try and get some subscriptions?
