[linux-audio-dev] Re: MIDI

Jens M Andreasen jens.andreasen at chello.se
Thu Nov 30 18:44:10 UTC 2006

On Sun, 2006-11-12 at 17:28 +0100, Pieter Palmers wrote:

[regarding midi over firewire]

> Note that this is already implemented in FreeBob. There is nothing 
> preventing us from setting up a (random number here)-channel MIDI link 
> over Firewire between one or more devices.
> A major issue however is discovering the devices and negotiating a 
> common stream format. This is not specified by the MMA, this spec only 
> describes the actual transfer of the MIDI bytes.
Pieter, I am not sure that I follow you correctly here. Using bad
car-anology: Is this like as if you have already build "The Golden Gate
Bridge", but there are still no "Highways" connecting to it? That there
is a sinc to throw the bytes into but no way for alsa to know about it?

In other words; is a device like M-Audio's 4ch audio in/out + 3 octave
keyboard useful as a performance instrument under Linux, or will the
keyboard be dead?

> Another showstopper is that every sender will need his own firewire 
> isochronous channel to send its data on, so that limits the number of 
> devices to 16. Keep in mind that the Firewire bus is one single domain 
> (for the Isochronous traffic), i.e. everybody sees everything.
Uhmm yes, but as I read from the paper, the midi transfer rate is (or
can be) quadrupled. Given that a home/stage setup with a single player
on a single cable works just fine latency-wise, wouldn't then 16*4 be
quite enough? At the risk of paraphrazing Bill Gates, but 64 staves
ought to be enough for anyone ... You could fit in two symphonic
orchestras, mixed choir, a couple of organs, a big band as well as an
extended Irish folk-group into that budget (and then some.)

Jokes aside: I don't see any external firewire computing devices where
one could send all those midi2 messages to. Anyone else?

> When using asynchronous traffic these restrictions don't apply but then 
> you lose the 'broadcast' advantage, making everything more complex.
> Pieter

More information about the Linux-audio-dev mailing list