|
2011-07-12 19:43
|
|
|
2011-07-12 19:44
|
|
|
2011-07-12 19:45
|
|
|
|
In a conversation with paul on IRC we gathered that 100 ms of offset (click -> track via external hardware - according to the described test setup) stem from the fact that the click (in contrary to regular tracks) currently is not latency compensated (see my new bug report/feature request 0004181). The cause of the additional 79 ms offset was not clear at this point. Some further testing showed that the offset is dependent on the highest cumulative latency of a track - tested with multiple plugs on a track as well as with plugs with different settings on multiple tracks. Some additional numbers wich hopefully help to determine the cause: offset latency factor 979 @1000 0,979 479 @500 0,958 179 @200 0,895 154 @175 0,88 129 @150 0,86 104 @125 0,832 79 @100 0,79 54 @75 0,72 29 @50 0,58 19 @40 0,475 14 @35 0,4 9 @30 0,3 4 @25 0,16 1 @22 0,0454545 0 @21 and below completely aligned So when the max latency is 21 ms or below the recordings are perfectly (sample accurate) aligned. Other things still to test: - how does it behave with different sample rates? - ...at different buffer sizes? I also checked A3 (rev. 9869) again and noticed that it only exhibits the offset caused by the nonexisting latency compensation of the click but doesn't show the additional offset. Track to track is perfectly aligned in A3! :) |
|
|
Some further testing with different sample rates and buffer sizes showed that the offset occurs as soon as the plugin latency exceeds the latency with wich jack has been started. With hardware inserts this will of course allways be the case. |
|
|
this should be fixed in current 2.0-ongoing SVN. i would appreciate a test. it was a lot of work! :) |
|
|
2.0-ongoing has a fix for the remaining issue. I was accidentally/inadvertently reversing the route list order during latency computation, causing the routes to be executed in the opposite order than intended, thus causing the appearance of latency. a3 didn't have this problem because the order of the route list is mostly irrelevant there. your testing assistance would be lovely. |
|
|
more fixes now update latency and capture alignment properties on transport stop, plugin add/remove etc, as used to happen. |
|
|
How are things with 2.8.12? |
|
|
Using the simple test setup from above this specific issue seems to be fixed (using SVN rev. 10158), but in a slightly more complex session there still seems to be something massively wrong with latency correction in general. I'm still investigating... :( Maybe this report should be closed and I'll open a new one and get on IRC when I manage to narrow things down a little more. |
- Anonymous
