[LAU] rtirq

[Len Ovens]

On Fri, 20 Mar 2015, Paul Davis wrote:

> 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.
> 
> this increases latency by 1 cycle, but eliminates jitter, which is the most
> desirable tradeoff.
> 
> 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.

  So a sequencer would be able to place the event correctly (by placing 
the event back in time), but a softsynth would be late by some variable 
amount of time between 1 sample and one cycle or at least could jitter by 
the length of a cycle plus whatever latency was added. I would think a 
sequencer would output an event one cycle early with a time stamp so it 
would hit the HW port on time. An external sequencer would create jitter 
while playing an internal softsynth, but I am not sure why anyone would do 
such a thing. However if they did, latency would probably be very 
important and so the jitter would be minimized as much as the cycle was 
minimized.

I'm thinking about this some more and a softsynth could add latency such 
that latency was constant. That is rather than playing imediately because 
it is late, it could delay by however much the event came in after the 
cycle it did come in on. I don't know if this is common practice though. 
Jack could impose this by making all event time stamps fit within the 
current cycle (use delayed time stamps). Because the jackmidi programming 
I was doing was control surface and I was not too worried about timing, 
all of my events were passed on the first sample of a cycle and incoming 
events where cycled through and read as if they should be processed then 
too. So i didn't pay as much attention to time stamping as I should/could 
have. I don't know if it is even possible for an application to send an 
event that should be played in the next cycle.

--
Len Ovens
www.ovenwerks.net