View Issue Details
|ID||Category||Date Submitted||Last Update|
|0003290||features||2010-06-25 10:35||2020-04-10 20:14|
|Fixed in Version|
|Summary||0003290: Latency compensation for busses|
|Tags||No tags attached.|
|Users sponsoring this issue|
Total Sponsorship = US$ 300
2012-03-20 11:15: realhangman (US$ 50)
2012-11-12 23:32: philicorda (US$ 10)
2012-11-13 13:57: in0giro (US$ 10)
2013-02-17 20:44: spock (US$ 30)
2013-03-10 20:00: agivagan (US$ 10)
2013-03-11 10:44: Xzu (US$ 5)
2013-03-11 11:25: zth (US$ 5)
2013-12-27 10:03: vervelover (US$ 5)
2013-12-27 13:40: ahellquist (US$ 5)
2015-07-31 18:45: ma120mk11 (US$ 30)
2016-08-24 08:25: lpirl (US$ 30)
2016-08-25 23:18: mhartzel (US$ 50)
2017-05-01 10:33: laex (US$ 30)
2017-05-28 07:55: ryang (US$ 5)
2017-08-14 04:34: marcan (US$ 25)
||This would be awesome to have, maybe the most important of all post A3 features..|
||I agree. Lack of latency compensation makes many modern production techniques impossible.|
||+1 for this feature.|
||+1 (whenever devs get time after 3.0)|
+1 for this feature.
Very important and powerful.
||+1. Very wanted!|
||+1 from me too. Would love to see this at some stage|
||Another +1 here. This is essential for me to start using ardour full time.|
Today while testing latency compensation port of my LV2 plugin:
WARNING: latency compensation is not possible.
Still not working?
Sometimes I get:
LatComp: buffer resize in progress. latency-compensation-pending: 30 want: 40
LatComp: buffer resize in progress. latency-compensation-pending: 30 want: 50
LatComp: buffer resize in progress. latency-compensation-pending: 30 want: 60
But still it's not working.
There is no bus-latency compensation yet.
The messages you get are from internal aux-sends (sends have delaylines and are aligned).
There is a prototype for bus latency compensation but it's not ready and not merged in the main codebase.
Currently (Ardour 4.4) the latency compensation is only done during playback on tracks (files where Ardour can read future samples) and during recording (move recorded data to the correct position).
Neither Tracks nor busses have delaylines to align/compensate for other latent effects.
||I think this would be a very important feature to add to Ardour, so I will sponsor 50 $ for implementing it. It hope this additional sponsorship pushes the feature from the "somewhere in the future" list to "will be implemented soon list" :)|
||In the process of finally switching completely to Linux even for my professional work as sound engineer, this is one of the very few things I'd be more than glad to see implemented soon... Thanks a lot!|
A quick heads-up: Recent Ardour6-pre includes full latency compensation (incl. busses, sends and sidechains).
While Ardour6 is still largely incomplete and work-in-progress, any testing of latency-compensated routing is already welcome.
PS. transport remains a work in progress. There is no de-click yet, no backwards playack. Also un/bypassing latent plugins while rolling will currently abort().
Keep in mind that Ardour6 session-format is not yet frozen, so do not use ardour-git or https://nightly.ardour.org builds for anything other than testing.
||Great to hear! Just curious, how does it work in Ardour6? Do delays get inserted to equalize latencies through the routing, and then all tracks play ahead to compensate for the overall delay? Does it work for MIDI too?|
Yes, there is a delayline after the disk-writer, before the disk-reader (and in sends and bus inputs). Incoming signals can be delayed to line up with data that is read ahead from disk. Overall clock-alignment is the master-bus' output.
The delaylines also handle MIDI. However at this point in time, MIDI in Ardour6 is still seriously broken.
I'm curious about how it would handle a hardware synth (or even an external software path that isn't hosted by Ardour). Can I send MIDI out from a track to a MIDI output, then have audio input from the synth into a bus, and have it line up? If clock alignment is based on the master bus, then what does it do about tracks that don't chain to the master bus from Ardour's point of view? Obviously the latency of the hardware synth would have to be represented somewhere (possibly a dummy plugin), but I'm more interested in how the latency graph ends up looking in cases where Ardour isn't necessarily aware of external loopbacks and connections (or whether there's a way to make it aware of that). I guess it's always going to be "hackable" to work by throwing in some dummy latency in the MIDI path that lines up with the synth latency + the entire audio return path within Ardour, but ideally the latter part would be somehow taken into account automatically, since it might vary as things move around.
(FWIW I'm a developer, I'm happy to poke a stick at this problem, run some tests and see if everything works as it should or try to improve it if it's helpful).
Yes, obviously Ardour can only compensate for known latencies.
Ardour comes with a built-in tool to measure and calibrate systemic I/O latencies of all Audio/MIDI I/O per device for all Ardour's built-in backends (JACK does not allow to compensate for hardware MIDI latencies).
The main case however is complete internal compensation for all tracks and busses and aligning outputs (bus stem export, etc).
If a hardware synth itself is latent (in addition to the normal MIDi -> Audio I/O path), that can not currently be automatically compensated. Ardour's "insert send/return" pairs only allow to measure external audio latency.
However hardware synths don't usually have significant latency by themselves. besides, I don't know how one could measure a HW synth's latency. do you?
Sending a MIDI panic, wait a bit, send a note-on, hope the synth generates some immediate audio, measure the time it takes and then subtract know systemic I/O latency. Sounds very fragile.
I'm tempted to say that's out of Ardour's scope. Only few users do use hardware synths and if you really have a latent one, you can just manually override it.
What I'm trying to figure out is how it works for hardware synths fed back into Ardour.
For example, let's say the MIDI hardware latency is 10ms, the hardware audio latency is 8ms, and there is 5ms of processing in the MIDI output path of a track. Now the track needs to play 15ms ahead of the transport position for the hardware output to be in sync. But now I hook up a hardware synth to the output, which for the sake of the argument let's say has zero latency. Its output is fed back into a bus, which has 5ms worth of processing on it, and then goes out to the master bus. Now there is 13ms of extra latency in the audio path, so that MIDI track actually needs to play 28ms ahead of the transport for it to e.g. line up with audio tracks at the master bus, but Ardour doesn't know that. I could add the extra 13ms as a dummy plug-in on the MIDI track, but now if I change the latency of the audio path (e.g. by adding a latent plugin), that needs to be adjusted again. So we're back to the situation where there is no latency compensation for busses, when Ardour doesn't know about the signal path through a hardware or external module and back into Ardour. Is there a way to represent this relationship to Ardour so that it can compensate for the full-path latency?
(I don't know if this is what would actually happen; I'm trying to understand how this all is supposed to work).
I realize that automatically measuring latency for a hardware synth path is difficult, but I'm not too worried about the *automatic* part. As long as I can dial in a number manually, that's fine.
Incidentally, my "hardware synth" is a Korg Kronos, which is itself internally an x86 Linux box running some synth as a kernel module on an RTAS subsystem, with all audio I/O going through a daughterboard hooked up via internal USB. Suffice it to say, it has latency. Not much, it's impressive for that design, but it does have some. Maybe I should write a qemu LV2 wrapper to virtualize its entire OS and the I/O and stick it into Ardour as a plug-in, that way it's not a hardware synth any more :-)
".. but Ardour doesn't know that."
Except it does, if the I/O port is calibrated to correct capture/playback latency and the port-flags are set:
You connect the MIDI track's output to a "physical" port that reports 10ms playback latency, and the bus' input to a "physical" port that reports 8ms capture latency.
Ardour would in that case delay everything else by 8ms -- and the track reads 15ms ahead (10 playback, plus the 5ms of FX latency).
This is pretty much like play Audio track -> [speaker|mic] -> bus -> master. It works only as long as the track itself is not connected to master, and the bus has no other inputs.
Likewise multiple external connections in series: bus 1 -> hardware I/O -> bus 2 -> hardware I/O -> bus 3 cannot be compensate for. Each I/O adds an additional cycle which is unreasonable. Direct outs allow for ambiguous routing and plenty of ways to shoot yourself in the foot. It's not something that can be reasonably handled by Ardour.
The main goal is to align all internal-sends, and routing where Ardour does have control over, as well as default I/O (overdubs, external clock sync etc).
Anyway, yes, you can enter custom latencies for each processor or add a virtual latency plugin that only reports latency on strategic points. Also on busses.
||I donated my $50 today since this feature is now in Ardour 6.|
||Good point. I subscribed since signing up to support this, but it's a huge deal and definitely worth the $25 on top of the subscription. Donated!|
||Probably not the place to ask this, but I sponsored this feature for a few bucks as well, and I'm not seeing where I can fulfill that commitment. Can anyone point me to the correct way to donate? Sorry and thanks.|
||When Ardour 6 is released, we'll ask you to https://community.ardour.org/donate the pledged amount.|
Thanks. Again sorry in advanced for asking in the wrong forum, but one last question and then I'm done. Is there any disadvantage to sending the pledge early? Does it mess up your tracking or anything? I'd go ahead and send it now unless there is a reason to wait.
Thank you and I'll shut up.
To be honest, the "bug bounty" system here is fairly weak. On the one hand, it rarely raises enough pledges to really justify the work required for most of the requests. On the other hand, there's also no mechanism to automatically collect or enforce anyone's pledge.
As a result, this is all fairly informal. We very much appreciate it when people make pledges and follow through on them, and sometimes we'll remind you of a pledge if appropriate.
|2010-06-25 10:35||cth103||New Issue|
|2010-06-25 10:35||cth103||cost||=> 0.00|
|2010-06-25 10:35||cth103||Status||new => acknowledged|
|2011-11-07 14:27||vervelover||Note Added: 0011926|
|2012-03-20 11:15||realhangman||Sponsorship Added||realhangman: US$ 50|
|2012-03-20 11:15||realhangman||Sponsorship Total||0 => 50|
|2012-11-12 23:32||philicorda||Sponsorship Added||philicorda: US$ 10|
|2012-11-12 23:32||philicorda||Sponsorship Total||50 => 60|
|2012-11-12 23:33||philicorda||Note Added: 0014223|
|2012-11-13 13:57||in0giro||Note Added: 0014236|
|2012-11-13 13:57||in0giro||Sponsorship Added||in0giro: US$ 10|
|2012-11-13 13:57||in0giro||Sponsorship Total||60 => 70|
|2013-02-17 20:44||spock||Sponsorship Added||spock: US$ 30|
|2013-02-17 20:44||spock||Sponsorship Total||70 => 100|
|2013-02-17 20:46||spock||Note Added: 0014654|
|2013-03-10 20:00||agivagan||Sponsorship Added||agivagan: US$ 10|
|2013-03-10 20:00||agivagan||Sponsorship Total||100 => 110|
|2013-03-11 10:43||Xzu||Note Added: 0014706|
|2013-03-11 10:44||Xzu||Sponsorship Added||Xzu: US$ 5|
|2013-03-11 10:44||Xzu||Sponsorship Total||110 => 115|
|2013-03-11 11:25||zth||Sponsorship Added||zth: US$ 5|
|2013-03-11 11:25||zth||Sponsorship Total||115 => 120|
|2013-03-11 11:25||zth||Note Added: 0014707|
|2013-12-27 10:03||vervelover||Sponsorship Added||vervelover: US$ 5|
|2013-12-27 10:03||vervelover||Sponsorship Total||120 => 125|
|2013-12-27 13:40||ahellquist||Sponsorship Added||ahellquist: US$ 5|
|2013-12-27 13:40||ahellquist||Sponsorship Total||125 => 130|
|2013-12-27 18:31||Leatuspenguin||Note Added: 0015512|
|2015-07-25 19:47||jameso||Note Added: 0016953|
|2015-07-31 18:45||ma120mk11||Sponsorship Added||ma120mk11: US$ 30|
|2015-07-31 18:45||ma120mk11||Sponsorship Total||130 => 160|
|2015-12-28 16:17||SadKo||Note Added: 0017746|
|2015-12-28 16:26||SadKo||Note Added: 0017748|
|2015-12-30 10:14||x42||Note Added: 0017756|
|2016-08-24 08:25||lpirl||Sponsorship Added||lpirl: US$ 30|
|2016-08-24 08:25||lpirl||Sponsorship Total||160 => 190|
|2016-08-25 23:17||mhartzel||Note Added: 0018486|
|2016-08-25 23:18||mhartzel||Sponsorship Added||mhartzel: US$ 50|
|2016-08-25 23:18||mhartzel||Sponsorship Total||190 => 240|
|2016-08-25 23:23||x42||Assigned To||=> x42|
|2016-08-25 23:23||x42||Status||acknowledged => assigned|
|2017-05-01 10:33||laex||Sponsorship Added||laex: US$ 30|
|2017-05-01 10:33||laex||Sponsorship Total||240 => 270|
|2017-05-01 10:36||laex||Note Added: 0019645|
|2017-05-28 07:55||ryang||Sponsorship Added||ryang: US$ 5|
|2017-05-28 07:55||ryang||Sponsorship Total||270 => 275|
|2017-08-14 04:34||marcan||Sponsorship Added||marcan: US$ 25|
|2017-08-14 04:34||marcan||Sponsorship Total||275 => 300|
|2018-08-29 21:18||x42||Note Added: 0020376|
|2019-08-11 04:51||marcan||Note Added: 0020714|
|2019-08-11 13:14||x42||Note Added: 0020715|
|2019-08-11 17:49||marcan||Note Added: 0020716|
|2019-08-11 19:00||x42||Note Added: 0020717|
|2019-08-11 19:27||marcan||Note Added: 0020719|
|2019-08-11 20:07||x42||Note Added: 0020720|
|2019-08-11 20:16||x42||Note Edited: 0020720||View Revisions|
|2020-04-10 07:14||mhartzel||Note Added: 0021277|
|2020-04-10 07:27||marcan||Note Added: 0021278|
|2020-04-10 18:02||ryang||Note Added: 0021284|
|2020-04-10 19:41||x42||Note Added: 0021286|
|2020-04-10 19:45||ryang||Note Added: 0021288|
|2020-04-10 20:14||paul||Note Added: 0021292|