Michael Ost wrote:
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.
this could be an option.
of course, mine was only an example that even uncompressed MIDI would provide a really high
A couple of thoughts:
Midi seems very compressable. You'd get a lot of 0x90s and 0x80s, for
instance. Is that worth pursuing?
midi events/second rate.
Is some sort of 'sequence' number needed to make sure packets arrived inUDP does not provide a guarantee that packets arrive in order but I think if the network is not saturated
the right order? Or perhaps UDP manages that...?
(which is MANDATORY otherwise we get choppy audio) and we use a simple windowing approach
where we enqueue 1-2 more packets in advance (as in my proposal) the probability of getting a packet
relative to 2-3 process() cycles ago is pratically zero.
Of course we need to write the benchmarks that prove this (under high network load (but not an overloaded network)).
If we do such simulation via benchmark and run it 1-2 days without getting out of order packets or losses we can
claim it works well for professional audio.
USB MIDI is certainly faster than serial MIDI (but I don't know how much faster), the problem of USB isIn 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?
AFAIK that the bus is polled each msec or so this means that raw midi I/O
(eg a midi keyboard connected to PC via USB midi interface) is affected from a bit of jitter , which is not present
in serial midi (since it has a constant clock).
Probably not a big issue. But USB MIDI interfaces do not provide timestamped midi events
(there are some exceptions like the ones from Emagic).
yes it's just a matter of writing the software, any kind of audio interface API, plugin interface like VST/AU can be used
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.
as a client for those jack network clients.
We're (Muse) also very interested in this sort of technology. We'd mostAFAIK you can limit the datarate of VNC traffic and as Steve said if you enable QoS things should go well.
likely want to run VNC alongside a protocol like this. Do you think that
would saturate a 100 base T network?
(Linux provides that and it's mostly only required on the transmission side (the linux box, muse is linux too :) ) since most traffic VNC generates is from the server (muse box) to the client (a windows PC).
Muse may be able to provide some programming resources if things work
out for us and the proposal looks good.
cool.
As said the ideal would be if there was a community effort to push such a solution forward, just like the
jack system, LADSPA etc was created.
I'l note that rolling yet another MIDI over UDP/TCP protocol is really stupid, there are 3 that I know of: IEEE-whatever, RTP-MIDI and OSC.
Steve, I'm not a big fan of reinventing the wheel,
the problem is here we are talking about combined audio and midi into single packets (for performance reasons),
high datarates (much higher than 30-64kbit VOIP apps) etc.
There is no IEEE RFC for now that covers our problem offering an optimal solution.
As said let's keep discussing, trying out proof of concept code, fail , iterate again and see what comes out.
as usual :)
cheers, Benno http://www.linuxsampler.org
