22 Jun
2004
22 Jun
'04
2:39 p.m.
On Mon, 2004-06-21 at 23:20, Benno Senoner wrote:
Since we want sample accurate midi triggering (which
traditional MIDI
over serial does not provide) we could do the following:
a MIDI command is usally not longer than 3 bytes (let's forget abut
sysex etc for now).
Perhaps sysex calls for a second midi-only packet type. Sysex could be
encoded as a start packet and some number of continuation packets. A
midi only packet could also let a driver send more than the 344 midi
messages at a time you spec'd out, if it needs to.
we could divide 400 bytes into 100 midi events
consisting in:
1 byte timestamp relative to the audio fragment (0-127) , this would
limit the fragmentsize to max 256 frames
3 byte midi payload
A couple of thoughts:
Midi seems very compressable. You'd get a lot of 0x90s and 0x80s, for
instance. Is that worth pursuing?
Is some sort of 'sequence' number needed to make sure packets arrived in
the right order? Or perhaps UDP manages that...?
In the case of serial MIDI you achieve a maximum about
(3byte MIDI
events) 1000 events/sec.
In our case we send about 344 packets/sec which multiplied with 100 midi
events gives us
34400 events/sec which are SAMPLE ACCURATE !
basically it would be like having the equivalent 34 midi interfaces.
Do you want to take a stab at a comparison with USB based MIDI?
Such a (bidirectional) audio/midi stream would consume
about
500KByte/sec , which means a 100Mbit LAN could run 10-15
of those at the same time without loosing data.
basically it would work as follows:
client PC (has an audio card) <----> jack server PC (runs jackd and jack
clients like samplers, softsynths, HDR apps etc, no audio card).
the client PC would run a jack network client which does the client PC
<---> server PC communication
the server PC has a special (not implemented yet) jackd input/output
driver which recieves/sends the audio data to the network,
for the rest the jack clients residing on the server PC don't know
anything about the network, to them it looks like a standard jack server.
The "clock" to the jackd residing on server PC is given by the client PC.
A Windows/Mac/ASIO driver-like interface would extend the usefulness in
lots of studios.
We're (Muse) also very interested in this sort of technology. We'd most
likely want to run VNC alongside a protocol like this. Do you think that
would saturate a 100 base T network?
Muse may be able to provide some programming resources if things work
out for us and the proposal looks good.
- mo