I've been testing ardour3 sending MTC via jack-midi and encountered the
following issue: Instead of receiving continuous MTC quarter-frames
ardour3 sends duplicate MTC-messages IFF the jack-buffersize is large
(>=512).
I've tracked it down.. to libs/midi++2/jack_midiport.cc
and eventually libs/evoral/evoral/Event.hpp
What happens is that jack_midiport.cc:148
vec.buf[0]->set (msg, msglen, timestamp);
does _not_ copy the midi-message into the ring-buffer, but stores a
pointer to it in the ring-buffer.
Since libs/ardour/session_midi.cc re-uses the same memory for each
message, the last midi-message is repeated x-times (the total number of
MTC quarter-frames is correct, just not the data) when ardour3 needs to
send multiple MTC-frames per process-loop.
ardour3 here is r7215 from
http://subversion.ardour.org/svn/ardour2/branches/3.0/gtk2_ardour
I dunno if the following is a proper fix or only workaround, but it
resolves the problem.
--- a/libs/midi++2/jack_midiport.cc
+++ b/libs/midi++2/jack_midiport.cc
@@ -145,8 +145,10 @@ JACK_MidiPort::write(byte * msg, size_t msglen,
timestamp_t timestamp)
}
if (vec.len[0]) {
+ vec.buf[0]->set_buffer(0,NULL, true);
vec.buf[0]->set (msg, msglen, timestamp);
} else {
+ vec.buf[1]->set_buffer(0,NULL, true);
vec.buf[1]->set (msg, msglen, timestamp);
}
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