[linux-audio-dev] MIDI interface latency

[David Olofson]

On Thursday 12 February 2004 20.30, jrobbins at nymu.net wrote:
> Anybody know what's the minimum latency that can be achieved
> passing MIDI notes from one computer to another?

Depends on the wire. For standard 31250 bps MIDI cables, the minimum 
latency for a NoteOn message (status, pitch, velocity - three bytes) 
is 0.96 ms. (It is one start bit and one stop bit, right...?)


> I'm wondering if it's possible in theory to set up an audio
> generation cluster to be used as a realtime instrument.

It's definitely possible in theory, though there's no avoiding that 
latencies add up. You just have to keep "internal" latencies low 
enough that the total system latency is acceptable. (No more than 10 
ms for a real time synth, I'd say. That is assuming the latency is 
*constant*!)


> Basically,
> have a network aware synthesis app running on all machines,
> administer the setup/modification of the signal flow architecture
> from one master machine in non-rt over sockets, and then pass notes
> to the appropriate machines using midi interfaces.

MIDI wire latencies are OK for normal use, but I'm afraid it can build 
up too much if you "chain" machines together this way. What's worse 
is that most of the latency will be caused by the application and/or 
OS, unless you use a hard RTOS, like RTL or RTAI.

Why not use ethernet hardware for everything? Good NICs with proper 
drivers have worst case latencies in the microsecond range on a 
dedicated network, and you'll need an RTOS anyway, so you kind of get 
a fast low latency network for free... MIDI interfaces can't possibly 
do any better anyway, unless the NICs are crippled by the drivers 
somehow. (A protocol stack that isn't designed for RT networking 
could cause trouble, obviously.)

One way to use NICs would be to drop the protocol stack and just use 
the NICs as high speed serial interfaces. You could use cross-over 
cables and point-point connections only, to completely avoid the risk 
of collisions and the related "random" latencies that may cause. 
(Though that's really protocol dependent, and not a general 
requirement. RT network streaming protocols tend to use token passing 
or similar techniques to guarantee bandwidth and latencies. It's 
virtually to impossible to do it reliably any other way, AFAIK.)


> Naturally this
> depends on a signal path separable into big chunks.

Yes... Or rather, the number of node->node hops is restricted by the 
connection latency, internal latency of nodes and the required total 
system latency. Use RTL or RTAI, fast NICs, cross-over point-point 
connections and process say, 0.1 ms' worth of audio/MIDI data at a 
time, and you can send data around quite a bit before you even reach 
the "magical" 3 ms. Unfortunately, processing that small chunks of 
data isn't terribly efficient, so at some point you'll undo the 
advantage of having more CPU power available.


> I have a hunch
> that midi over ip has latency too high and unpredictable for this.

Only if the OS and/or the protocol stack is not real time capable, or 
if some non-RT machines are on the same network.

(With standard hardware, there's no way you can force a babbling 
Windoze box or something to get off the network when you want to chat 
with your RT peers, so you just have to make sure everything on your 
RT network agrees with, and is physically capable of obeying the 
rules of that network. RTOS and RT network protocol support is a 
minimum requirement for every node.)


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---