![]() ![]() In the screenshot below, you see two lanes. ![]() I take some time to redo my lost report (I've a very tight schedule ATM) It'd be interesting if this is exactly half of the buffer-size. ![]() This tests alignment of Audio out vs MIDI out. I'd also start at a time other than 00:00:00:00 first. Record the audio of the slaved synth and Ardour's master-bus audio output with a different device (or an independent Ardour session) and see if the audio aligns. Could you describe your test setup? It'd be great if I could reproduce it somehow.Īre you perhaps directly feeding Ardour's MIDI clock output back into an Ardour Audio port? That could explain the 1 cycle offset. > BUT: now externally synced gear is ONE buffer late. However we can only measure **round-trip** latency (MIDI out -> MIDI in, Audio out -> Audio in), the absolute alignment of MIDI-out -> Audio in is unknown. The MIDI signal is likewise aligned, and sent early by difference of Audio - MIDI port playback latency. The clock (and playhead position) matches "what you hear at the speakers". Both Audio and MIDi calibration are in use and port latencies are set correctly.Īrdour's clock is aligned to the master-bus's output (incl. ![]() > I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages. Thanks for the feedback! So we're making progress at least. Check if the click is aligned on the grid. Patch Ardour click to an audio track input, record metronome. Check if the click is aligned on the grid.Įven when routing internally, there's an issue: Patch the sequencer's audio click output into a audio interface input, and connect to a Ardour track. Patch midiclock to the midiport a sequencer is connected to. Make sure audio and midi have been calibrated. I downloaded Ardour to doublecheck and it has the same behaviour. When a external sequencer receives a start message, and we record its (audio) metronome, the record metronome shoul be perfectly aligned on the grid. This means that all latency compensation should apply to these RT messages too. The Real Time start/continue/stop messages should be sent when the actual audio starts to sound, so that synced external sequencers are synced to the recorded audio. When using the midi device calibration results, the offset is worse than when leaving them at default 0. On the other hand, audio latency compensation is spot on: I have correctly calibrated the audio hardware and it’s sample accurate. I spent countless hours checking every possibility I could think of, and reported the issue to Harrison support. They start/continue messages are always sent too early in relation to the grid, and this offset seems to be related to some latency compensation: if I insert a plugin that needs PDC (even the limiter on the main bus) the start/continue messages are issued even earlier but I did not identify a clear sample-accurate pattern. I have an issue with the midiclock and/or the start/continue messages. 0008153: Midi Real Time messages are sent too early (Mixbus AND Ardour) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |