On Friday 10 September 2004 05:50 pm, Martijn Sipkema wrote: > > > The problem here is that class compliant devices suffer bad timing > > > because they use bulk transfers for MIDI data. The standard for > > > MIDI over FireWire is much better. > > > > I don't agree on the subject that USB bulk transfers cause bad MIDI > > timing. Of course, you can't use the same USB host controller at a time > > with a MIDI interface and some other device like a CD writer and expect > > both good MIDI timing and fast CD burning. If you can reserve a host > > controller exclusively for your USB MIDI device, you will get pretty good > > results, most of the time. > > [...] > > > - Isochronous transfers send or receive data streams in realtime with > > guaranteed bus bandwidth but without any reliability. > > [...] > > > MIDI streams need to be reliable (a single byte lost isn't acceptable), > > so Isochronous is not an option. Interrupt or Bulk transfers are very > > similar: they use only the available bandwidth at each moment, so there > > can be unwanted delays and timing problems. Some manufacturers' > > proprietary protocols include a timestamp with each USB MIDI packet to > > enhance the time accuracy, but this can be done either in bulk or > > interrupt transfers. > > MIDI streams need a reliable transport with guaranteed bandwidth. If > USB can't provide this, then it is not really suitable for MIDI, but I'm > not saying it is unusable, just that it may perform worse then traditional > serial multiport MIDI interfaces. >
FWIW the M-Audio keyboard I bought has a regular MIDI interface too. I'd imagine one with audio inputs has it as well. > --ms
