View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009989 | ardour | bugs | public | 2025-08-26 14:32 | 2025-08-26 14:32 |
Reporter | lina | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Platform | GNU | OS | Linux | OS Version | (any) |
Product Version | 8.12 | ||||
Summary | 0009989: Default recording alignment is incorrect for internal monitoring | ||||
Description | When recording with software (Ardour) monitoring, the default alignment for tracks should be "Align with Capture Time" When using software monitoring, our ears hear the audio through the software chain with any latency that it introduces. The brain internally compensates this latency (as long as it is reasonable), so that the heard audio is in sync. This applies to both singing and playing MIDI instruments. That means that the alignment point of audio recorded with software monitoring is Ardour's *output*. This is "Align with Capture Time". The "Align with Existing Material" setting will result in audio that is recorded too early, which then thanks to Ardour's latency compensation, is still played back too early. Put another way: The exact mixed audio heard during recording with software monitoring should be what is played back when the recording is subsequently played back. | ||||
Steps To Reproduce | - Configure Ardour for software monitoring ("Record monitoring handled by: Ardour") - Create a new audio track, arm it for recording (which enables monitoring) - Create a less than unity gain feedback loop (e.g. headphones on top of mic, adjust volume so that there is an audible and visible delay effect visible on the waveform but it does decay) - Enable click - Record some audio onto the audio track The recorded audio consists of a decaying feedback delay effect per click, with the time between repeats equal to the round-trip system delay. With the default "Align With Existing Material" (selected by the "Automatic") setting, and with hardware latency correctly configured (or when the period size is significantly higher so as to make hardware latency negligible in comparison), the primary/first click is aligned with the beat grid. This is (counter-intuitively) wrong. Since there is no brain in the loop, the monitored clicks are actually too *late*, and so should be recorded delayed vs. the beat grid. |>-->-->-- | Changing the track to "Align With Capture Time", the clicks are recorded delayed off-grid (shifted to the right), which is actually correct, since that is what was heard (the delayed feedback was, in fact, delayed vs. the primary click). | >-->-->-- | If this were a real human singing perfectly instead of a dumb loop, the first case would have the recording earlier than the grid, while the second case would have the recording perfectly on grid. | ||||
Additional Information | This all works the same when there is latency introduced by Ardour itself, such as adding a latent plugin to the recording track. This increases the system round-trip latency, but the relative compensation is still correct ("Align With Capture Time" correctly delays the recorded audio by the sum total of the engine, hardware, and Ardour round-trip latency). It's debatable whether the setting should change based on the "In" per track setting, or based on the global monitoring config. Since the alignment cannot be changed while recording, and the "In" setting can, I argue that it should follow the global monitoring setting. In other words, when Ardour is configured for "Record monitoring handled by: Ardour", tracks connected to hardware inputs should default to "Align With Capture Time" in auto mode. This change does mean, of course, that someone who has Ardour configured globally for software monitoring and then uses hardware monitoring for some tracks (overriding the mode to "Disk") will have to switch them back to "Align With Existing Material" to get the expected results. I don't think it's possible to make this changeable during recording without introducing discontinuities, and guessing based on the state of the In/Disk settings at recording start would lead to unintuitive results if they are changed midway, so I think it should just follow the global monitoring setting. All this also applies to MIDI tracks. MIDI tracks recorded while listening through a software MIDI instrument should be aligned as "Capture Time" to end up aligned properly when playing naturally. I'm not sure if it makes sense to follow the global monitoring setting for these too though. It's all a bit confusing and unintuitive no matter what you default to... maybe there should be a comprehensive doc written about all this too? There's also a related bug: If *multiple* tracks are armed for recording and recording from the *same* input (MIDI or audio, doesn't matter) and all set to "Capture Time", and they have *different* processing delays (e.g. one has a latent plugin, another does not), then Ardour seems to insert a compensation delay to the less-latent tracks to keep the round-trip latency the same through all paths. This is correct, *but*, it is not compensated correctly when recording. When recording, the track with the highest processing latency will be adjusted correctly, but the others will not, even though they do have "phantom" delay added to match the latent track so in practice the recording compensation should be the same for all tracks. | ||||
Tags | No tags attached. | ||||
Date Modified | Username | Field | Change |
---|---|---|---|
2025-08-26 14:32 | lina | New Issue |