I was using the ubuntu version two releases back and was having trouble recording a guitar rhythm track. It was way off. I tried recording the click or re-recording a drum track by going full round trip and both end up late on the grid and/or the original track. Then I saw there was a recent compensation bug fix here so I got the latest version of ubuntu with a much newer version or Ardour. The version number I have now is in the 7 thousands and the bug fix was in the sixes.
But it still records the click late. In fact, you can see it start the track (graphically) a bit late at first (after the playhead has moved) and then fill in back to the start (again graphically) after about a second when it renders the first patch of audio.
Is there something wrong with the Ubuntu version? No I’m not using rt just relying on compensation to position my overdubs wrt the current material. Hardware monitoring on, delta 44, the default jack settings, jack latency in the 40 something ms range.
Since it actually starts the graphical track late, I doubt this can be blamed on hardware or anything else. If it had shifted the region by the “lateness gap” it looks like it would be right. In fact if it would leave that gap in the region, I could just drag it back.
there are bugs with this in all released versions of ardour2. a fix will be in the next release (and is already in svn)
people also often run into problems with this when they create a new track, connect it to an existing track (or output like the click) and do not disconnect the new track from its existing (physical) inputs. you need to be sure you have done this because otherwise ardour has conflicting information on the signal latency arriving at the new track, and no single answer can be correct.
Bug report I am referring to. Is this fix not in Ardour 2?
@teebird: i edited my comment, be sure oto see the update.
Thanks, makes perfect sense. I’ll check all the connections to the new track, but I did record the click “through the air” into a mic.
Edit: a very close mic to monitor spkr (1 ms per foot at sea level )
I had a similar question that I posted to the JACK email list recently, and my experience may be useful in your case.
I was using the alpha 4 build of Ardour 3, and found that latency compensation worked much better when I installed the latest version of JACK. There was a 10x difference in the effectiveness of the latency compensation by using the latest JACK (with jack 1.9.6 the tracks were offset by about 130ms, with latest jack2, the tracks were offset by about 13ms, same audio interface, same settings.)
I also found that using my PCI card interface resulted in much less offset than using my USB interface (around 0.07ms offset with the PCI card, compared to 13ms with the USB interface).
Paul posted instruction today on the jack mailing list about how to use a software tool to actually measure the end to end latency of the hardware, and then input that to jack, so I’m going to see if using that method will allow the USB interface to perform as well as the PCI interface. I don’t think that usage of that tool is documented anywhere yet, so I’ll try to keep notes and see if I can write something to add to the jack faq.
Looks like I can compensate using my input latency on the old (from Ubuntu 9.10) version for now.
I think I had to use the output latency on the newer one to get some shift, but I’ll probably start using 3.0 next.
The graphical issue I noticed is not relevant.
ccaudle, could you please post the link to that message in the jackd mailing list?
Also, how can you tell jackd to report more latency than the latency actually happening so Ardour (I’m using 2.8.11, which still has the bug) aligns the new recordings properly?