[Ardour-Dev] ardour3 jack-midi MTC buffering bug & fix
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 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
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.
 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...
Size: 1916 bytes
Desc: not available
More information about the Ardour-Dev