Forums
However, it should be the same. There's no reason for the bus to affect whether or not it has an output when recording, as the track will always have an output. Therefore, output correction should also be applied.
This desyncs recordings made from the same source (interface) in mono (voice) and stereo (instruments) at the same time, as I want a mono input (for voice) but a stereo output, and a stereo input and output for instruments.
If I have multiple mics connected to an interface, the recording should remain synchronized, regardless of the type of bus I use for recording.
File attachments
re. Mono audio recording with different latency...
please explain your setup and how exactly you come to that conclusion.
what is the source, whether pipewire or genuine jack (this is very important even more so if you're relying on jack-transport to start playback on the source, if applicable) and notwithstanding anything else that are specific to your experiment and lead you to conclusion...
thanks
I misdiagnosed it
Corrected, I misdiagnosed it. It wasn't due to the channels.
I'm using Pipewire, but it doesn't matter in this case. The problem here is the offset correction in clips when recording with input-only buses. You should also apply the output correction, because even if the bus has no output, the track will always have one.
Corrected above.
Not using input buses avoids the problem
Using only duplex buses for recording avoids the problem.
However, the problem still persists.
The issue and a workaround have been reported, in case it's helpful to anyone.
This thread confuses me so I…
This thread confuses me so I must ask some questions and mention some things...
What do you mean by "recording"? Better yet, what is the source being recorded in this problematic scenario?
I ask the above because I have never seen these offsets introduced when I mixdown (my only "recording" scenario involving audio). When I "record", I'm recording the input of my MONITOR bus (2 channel Input) which is connected to the monitor ports of my audio device.
Probably also worth mentioning is that I never have audio tracks being output. Your screenshot shows multiple audio tracks so I'm assuming the last is capturing what the others are outputting? Even if I'm misunderstanding that screenshot, I may be hitting on a workflow or some assumption that may be worth elaborating on?
re. confuses
Let's see if the graph helps.
The problem is that when offset correction is applied to clips to compensate for latency in recordings, if the bus used for recording is input... it doesn't take into account the output latency... since it's an input-only bus.
However, the clip must have output offset, otherwise it will become misaligned.
In short, you always have to take output offset into account regardless of the type of bus used for recording, whether duplex (where the problem doesn't occur because it has an output) or input.
Ah yea, that does help. It…
Ah yea, that does help. It makes me realize even if my resulting recording does contain the offset, I don't care because the resulting track doesn't need to be in sync with anything. Thank you for elaborating :)
Everything is fine as it is... Qtractor wins again
It's deeply unintuitive, but after some testing, I confirm that the current behavior is the most versatile.
In summary:
1_External source:
If you want to record an external source through a sound card, set the bus to duplex. This will take into account input and output latencies.
2_ Internal source:
If you want to record an internal source (an audio application or monitor system), set the bus to Input. When recording internal sources, recording latency does not exist, since there is no recording process on the sound card. The audio is played directly, so only one latency should be applied, which is what happens if we configure the bus as Input.
Add new comment