<div dir="ltr"><div><div><div>jack MIDI bridges delay all MIDI events by 1 process cycle, after timestamping them with the offset into the current process cycle when they are received.<br></div><br></div>this increases latency by 1 cycle, but eliminates jitter, which is the most desirable tradeoff. <br><br></div>so a MIDI event arriving T samples into process cycle N will be delivered to clients in process cycle N+1 with a timestamp of T.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 7:52 PM, Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 20 Mar 2015, Joakim Hernberg wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
with jitter.  Further, at least on windows the midi isn't handled at all<br>
by the ASIO driver, so I doubt that the ASIO buffer size would have any<br>
impact at all on midi timing.  I think this is different on linux using<br>
jack midi, but i suspect that the alsa sequencer won't be tied at all<br>
to any buffer size that JACK uses.  I might be wrong about this though?<br>
</blockquote>
<br></span>
The alsa sequencer gets it's timing from the OS, It seems to say from the wall clock, but is in fractions of a second from when the alsa sequencer is started. Raw MIDI is just as soon as it comes in... but I am not sure what buffering there is or not. I would think that the buffer should be cleared each and every time any byte comes in. That would be the only way single byte midi rt commands could be real time. I do not see irq that belongs to my midi port (mpu401 clone), but it may be called from the ensoniq driver.<br>
<br>
I do not know how jack gets it's date stamp for a midi event ( or if that time is at the first or last byte of an event... jack deals with midi events) I would assume if it is using alsa-seq, it uses the time stamp from there. With raw I don't know. From Paul's comment, I would guess the sample at the end of the last buffer input plus time to calc current sample time stamp.<br>
<br>
jack1 uses ajmidid internally, and ajmidid is recommended forjack2 as well. I don't have a clue how time stamp is created with this.<br>
<br>
I think with firewire, the time stamp is a part of the transport... but it has been a while since I looked at it.<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" target="_blank">www.ovenwerks.net</a><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org" target="_blank">Linux-audio-user@lists.<u></u>linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-user" target="_blank">http://lists.linuxaudio.org/<u></u>listinfo/linux-audio-user</a><br>
</div></div></blockquote></div><br></div>