NOTE: This is a topic for advanced users
When you record audio into a computer, there are inherent delays caused by the conversion and buffering inside your audio system. When you finish a recording, Mixbus has to place the newly recorded region so it aligns correctly with the existing audio in the session. The value of this adjustment is the recording-offset latency, and Mixbus should manage this for you "automatically".
Particularly when you are adding new tracks to an existing recording, or "overdubbing" on parts of the existing recording, you want the timing to match the previously-recorded material.
If Mixbus is provided your hardware's inherent delays, the soundcard buffer size, and the latency of all plugins etc, then Mixbus should be able to place the audio correctly with "what you heard while you were playing".
Sometimes the hardware latency introduced by your A/D and D/A hardware isn't reported correctly to Mixbus. When that happens, we have to measure the latency by sending a signal through the D/A, and returning it to an A/D. The "calibrate audio" feature (near the bottom of the Audio setup Window) is intended to measure these delays. Once measured, Mixbus should use this value to further refine the placement of recorded audio regions to match "what you heard".
The "calibrate audio" feature works by sending a complicated mix of low, mid, and high tones through your I/O device's output, and then using the frequency content of the tones to determine, with great accuracy, how long it takes for the signal to be sent & received by your device. It is very important that your polarity of the wiring between your device's output and input is preserved. Some devices internally flip the polarity between the input and output (which is an indication of lax testing, but probably not a problem in regular recording usage). If the polarity is not preserved, then Mixbus will think there has been a "very long delay" from the output to the input, and this can result in nonsensical values from the calibration.
In practice, most users do not calibrate the system; as the hardware conversion latency is typically only 1-4 ms.
Furthermore, in semi-pro USB-based systems, this value can change with each launch of Mixbus, due to the internal motherboard USB stack. In this case, you'd have to recalibrate every time you launch Mixbus. PCI, Thunderbolt, and Firewire-based systems should not have this problem, but we don't know the internal operation of every motherboard, driver, firewire stack, and external device. So you can't guarantee that the latency is always valid.
As long as the basic rhythm tracks were recorded together, this is very unlikely to cause a problem. Future overdubs on these main rhythm tracks, even if they are individually delayed by 1-4 ms, will not affect the overall timing or "feel" of a performance.
So only the most demanding technical tasks should require using the latency-calibration tool. And this calibration should be tested regularly to make sure it is still valid. Most users can ignore this.
To determine the quality of your system calibration, you can enable the 'click' (metronome), and re-record it to a track in Mixbus (to do this, you should use a wire connection from your soundcard output, back into your soundcard's input). Then play back your recording of the click, with Mixbus's internal click still engaged, and determine whether any objectionable offset is heard.
In a best-case scenario, you should hear that the clicks are exactly aligned. In practice, because we are dealing with computers and a wide range of third-party drivers & devices, you might hear some offset. If the offset is very short ( where it's hard to differentiate 2 distinct "clicks"), then you can likely ignore the problem. It's essentially the same as using a mic 2-4 feet away from the source.
But if you hear a very objectionable delay, it is likely not the "calibration", but rather a software error, such as a plugin that isn't reporting its latency correctly to Mixbus.
There's one final bit if information that has been important in the past: Tracks must be compensated differently when they are "bouncing" from a track or bus, versus when they are recorded from a live A/D input. Mixbus should automatically detect when you are bouncing, versus recorded live. But in certain setups (for example if you are recording live but you -also- have a connection from a bus to the track) then Mixbus doesn't know which offset to choose (in fact there -is- no correct setting). You can check individual track latency-mode, and override it, by right-clicking on the track header and choosing "Alignment".
If you determine that Mixbus is failing to compensate the latency on your system, and it is more than a few milliseconds off, and you've verified that the track is using the correct alignment mode, and your plugins are reporting the correct latency value, then your only solution is to move the regions to the correct timing after they've been recorded. Assuming it's always the same offset, then you can set up the "nudge" feature to use that value, and "nudge" the regions to their correct location with a single selection/click.