[LAU] rtirq

[Paul Davis]

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.

On Fri, Mar 20, 2015 at 7:52 PM, Len Ovens <len at ovenwerks.net> wrote:

> On Fri, 20 Mar 2015, Joakim Hernberg wrote:
>
>  with jitter.  Further, at least on windows the midi isn't handled at all
>> by the ASIO driver, so I doubt that the ASIO buffer size would have any
>> impact at all on midi timing.  I think this is different on linux using
>> jack midi, but i suspect that the alsa sequencer won't be tied at all
>> to any buffer size that JACK uses.  I might be wrong about this though?
>>
>
> 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.
>
> 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.
>
> jack1 uses ajmidid internally, and ajmidid is recommended forjack2 as
> well. I don't have a clue how time stamp is created with this.
>
> I think with firewire, the time stamp is a part of the transport... but it
> has been a while since I looked at it.
>
> --
> Len Ovens
> www.ovenwerks.net
>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20150320/67b876f4/attachment.html>