[Ardour-Dev] ardour3 jack-midi MTC buffering bug & fix

Robin Gareus robin at gareus.org
Thu Jun 3 09:15:58 PDT 2010

On 06/03/2010 07:41 AM, Quentin Harley wrote:
> Paul Davis wrote:
>> very nice detective work robin, and thanks.

>>> Anyway there must be sth. else wrong with ardour3 generating MTC. It
>>> looks like it's lagging behind or generates them at wrong speed..
>>> Although that could be an issue with a2jmidi or jackd -Xseq
>> its in ardour3. its a known issue.
That's the good news.

> Described here: http://tracker.ardour.org/view.php?id=3059
...and that's the bad.

> Thanks for working on this Robin.  I tried giving it a go, but I am
> afraid to say that I got lost fairly quickly. 
tell me about it :)

> Just not programming regularly enough it seems...
In this case cscope & simple printf's were my friend. no wizardry involved.

Back on topic. With 95% confidence the problem is caused by:
  outbound_mtc_timecode_frame += _worst_output_latency;

and the tentative[1] fix is to just remove that line. It causes the lag
by adding the latency again and again for each full MTC-frame. The
latency should be added only _once_; and that is already done by

The 95% confidence is because I'm yet to fully grasp the call-graph
in libs/ardour/session_process.cc

It looks like send_full_time_code() is only called if the transport is
re-located or stopped. For the latency-compensation to work properly it
also needs to be called when ports are re-connected or after any
operation that causes _worst_output_latency to change.

I'm yet to bend my mind around this: but it looks like the latency is
compensated for twice: the msg_time of the MTC midi message uses the
timestamp from outbound_mtc_timecode_frame which already includes
_worst_output_latency and effectively voids the whole compensation, no?

I'll have a look again after a break.

...and now for something simple: Where has the "Slave to incoming MTC"
button gone? I only get to choose between "Internal" or "JACK" sync.


[1] actually just subtracting the latency from the jack-midi msg_time
and keeping outbound_mtc_timecode_frame in sync with _transport_frame
would me much cleaner; however implementing it that way with the current
in-process call might be tricky since the MTC messages would need to be
scheduled ahead in time.. mmh. any ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ardour3-r7217_mtc_fix.diff
Type: text/x-patch
Size: 1916 bytes
Desc: not available
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20100603/1bf2e06a/attachment-0002.bin>

More information about the Ardour-Dev mailing list