Re: [linux-audio-dev] a question re: the MIDI spec
It's not unusable, but IIRC it can get to several ms of jitter. Why is that? The USB iso clock is every ms IIRC, so naively you would expect the maximum jitter to be just under 1ms (if the bus was saturated by audio transfers), and less in proportion to the degree of saturation. USB transfers always wait for the beginning of the next frame, so the maximum jitter is never less than 1 ms, even on an otherwise free bus. Yes, one would expect that (if there are no other bulk transfers), but somehow this does not seem to be the case: http://www-2.cs.cmu.edu/~eli/papers/icmc01-midiwave.pdf These measurements include the jitter added by the drivers and by the high-quality realtime-capable (yeah :-) Windows 98 scheduler. I did some similar measurements under Linux, and it seems the jitter isn't bigger than the expected 1 or 2 ms (2 because MIDI through involves two USB transfers). Well, I still think they probably should have used interrupt of isochronous transfer mode, but 2 ms jitter is quite usable (although a 1 ms jitter would have been better and possible even with USB I think). --ms
Re: [linux-audio-dev] a question re: the MIDI spec
Martijn Sipkema wrote: It's not unusable, but IIRC it can get to several ms of jitter. Why is that? The USB iso clock is every ms IIRC, so naively you would expect the maximum jitter to be just under 1ms (if the bus was saturated by audio transfers), and less in proportion to the degree of saturation. USB transfers always wait for the beginning of the next frame, so the maximum jitter is never less than 1 ms, even on an otherwise free bus. Yes, one would expect that (if there are no other bulk transfers), but somehow this does not seem to be the case: http://www-2.cs.cmu.edu/~eli/papers/icmc01-midiwave.pdf These measurements include the jitter added by the drivers and by the high-quality realtime-capable (yeah :-) Windows 98 scheduler. I did some similar measurements under Linux, and it seems the jitter isn't bigger than the expected 1 or 2 ms (2 because MIDI through involves two USB transfers). Regards, Clemens
Re: [linux-audio-dev] a question re: the MIDI spec
[...] 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. USB can provide this just fine, as long as you don't share host controllers between MIDI and other devices. Common sense, really. I would think it would work fine even with multiple MIDI devices on the same bus, as long as you don't expect to run audio and MIDI over the same wire and have it work. I don't think common sense is to expect MIDI timing to degrade when using audio on the same bus, especially when a single device combines these features. With FireWire it _is_ possible to have both audio and MIDI (both use isochronous transfers) on the same bus without it hurting MIDI timing. USB audio would probably work with bulk transfers too if the bus wasn't used for anything else, so why did they choose isochronous transfers for audio? I don't see why a audio stream should be less reliable than a MIDI stream. --ms
Re: [linux-audio-dev] a question re: the MIDI spec
On Fri, Sep 10, 2004 at 10:40:05PM +0100, 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. [...] Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ Timing is especially bad when there is other data being transferred on Especially bad is still pretty vague. What might look bad on paper might be acceptable in context... It's not unusable, but IIRC it can get to several ms of jitter. Why is that? The USB iso clock is every ms IIRC, so naively you would expect the maximum jitter to be just under 1ms (if the bus was saturated by audio transfers), and less in proportion to the degree of saturation. - Steve
Re: [linux-audio-dev] a question re: the MIDI spec
[...] 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. [...] Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ Timing is especially bad when there is other data being transferred on Especially bad is still pretty vague. What might look bad on paper might be acceptable in context... It's not unusable, but IIRC it can get to several ms of jitter. Why is that? The USB iso clock is every ms IIRC, so naively you would expect the maximum jitter to be just under 1ms (if the bus was saturated by audio transfers), and less in proportion to the degree of saturation. Yes, one would expect that (if there are no other bulk transfers), but somehow this does not seem to be the case: http://www-2.cs.cmu.edu/~eli/papers/icmc01-midiwave.pdf --ms
Re: [linux-audio-dev] a question re: the MIDI spec
On Saturday 11 September 2004 01:28 am, Lee Revell wrote: On Fri, 2004-09-10 at 23:00, John Check wrote: 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. M-Audio's USB MIDI keyboards are great, but I would not expect the audio variant to work as well. I also would not expect the audio hardware to be any better quality than what is in your average laptop. I haven't tried it though. I wouldn't base a studio on one, but I don't think thats the idea anyway. Lee
Re: [linux-audio-dev] a question re: the MIDI spec
[...] the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html - USB class compliant-no drivers required for Windows XP or Mac OS X M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. 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. --ms
Re: [linux-audio-dev] a question re: the MIDI spec
On Fri, 2004-09-10 at 07:49, Martijn Sipkema wrote: [...] the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html - USB class compliant-no drivers required for Windows XP or Mac OS X M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. 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. Hmm.. I'm just about to drop $400 on a USB MIDI interface (Edirol UM-880), so that's not something I want to hear! Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ -DR-
Re: [linux-audio-dev] a question re: the MIDI spec
On Friday 10 September 2004 Eric Dantan Rzewnicki wrote: On Thu, Sep 09, 2004 at 07:18:57PM +0200, Pedro Lopez-Cabanillas wrote: And now Avid (the company owning Digidesign) bought M-Audio. [...] Really!?! when did that happen? http://www.avid.com/company/releases/2004/040820_acquisition.html http://www.m-audio.com/index.php?do=media.newID=503e85ec37f1003524a4455fcfb32b1f http://www.m-audio.com/images/en/press_releases/Avid-M-Audio_PR.doc Regards, Pedro
Re: [linux-audio-dev] a question re: the MIDI spec
On Fri, 2004-09-10 at 07:49, Martijn Sipkema wrote: [...] the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html - USB class compliant-no drivers required for Windows XP or Mac OS X M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. 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. Hmm.. I'm just about to drop $400 on a USB MIDI interface (Edirol UM-880), so that's not something I want to hear! Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ Timing is especially bad when there is other data being transferred on the same USB bus, as is the case with combined audio/midi interfaces. There are several USB interfaces that don't use the standard MIDI-over-USB protocol, but I don't think information about these protocols is available. Perhaps there are interfaces that support both the standard protocol and one with better timing... --ms
Re: [linux-audio-dev] a question re: the MIDI spec
On Friday 10 September 2004 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. There are four USB data flow types, Control transfers and: - Bulk transfers are used to request or send reliable data packets up to the full bus bandwidth. Devices like scanners or scsi adapters use this transfer type. - Interrupt transfers are similar to bulk transfers which are polled periodically. If an interrupt transfer was submitted the host controller driver will automatically repeat this request in a specified interval (1ms - 255ms). - Isochronous transfers send or receive data streams in realtime with guaranteed bus bandwidth but without any reliability. In general these transfer types are used for audio and video devices. (quoted from http://wwwbode.cs.tum.edu/Par/arch/usb/usbdoc/node8.html) 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. Regards, Pedro
Re: [linux-audio-dev] a question re: the MIDI spec
On Friday 10 September 2004 02:07 pm, Martijn Sipkema wrote: On Fri, 2004-09-10 at 07:49, Martijn Sipkema wrote: [...] the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html - USB class compliant-no drivers required for Windows XP or Mac OS X M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. 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. Hmm.. I'm just about to drop $400 on a USB MIDI interface (Edirol UM-880), so that's not something I want to hear! Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ Timing is especially bad when there is other data being transferred on Especially bad is still pretty vague. What might look bad on paper might be acceptable in context... the same USB bus, as is the case with combined audio/midi interfaces. Perhaps, but midi takes a lot less bandwidth than audio so how much worse could it get? It sounds like it wouldn't be a problem if you were overdubbing, but potentially in a live recording/performance if you are using the audio ins for a vocal mic or whatnot. There are several USB interfaces that don't use the standard MIDI-over-USB protocol, but I don't think information about these protocols is available. Perhaps there are interfaces that support both the standard protocol and one with better timing... --ms
Re: [linux-audio-dev] a question re: the MIDI spec
[...] 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. [...] Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ Timing is especially bad when there is other data being transferred on Especially bad is still pretty vague. What might look bad on paper might be acceptable in context... It's not unusable, but IIRC it can get to several ms of jitter. the same USB bus, as is the case with combined audio/midi interfaces. Perhaps, but midi takes a lot less bandwidth than audio so how much worse could it get? It sounds like it wouldn't be a problem if you were overdubbing, but potentially in a live recording/performance if you are using the audio ins for a vocal mic or whatnot. I'm by no means an expert on this, but I think MIDI taking less bandwidth than audio is not really relevant; it's audio data being isochronous and using a lot of bandwidth causing the MIDI timing to suffer. --ms
Re: [linux-audio-dev] a question re: the MIDI spec
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. --ms
Re: [linux-audio-dev] a question re: the MIDI spec
On Fri, 2004-09-10 at 17:50, 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. USB can provide this just fine, as long as you don't share host controllers between MIDI and other devices. Common sense, really. I would think it would work fine even with multiple MIDI devices on the same bus, as long as you don't expect to run audio and MIDI over the same wire and have it work. Lee
Re: [linux-audio-dev] a question re: the MIDI spec
On Friday 10 September 2004 05:40 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. [...] Is the timing really that bad? I don't even think a firewire 8x8 rackmount MIDI interface exists, so my options are kinda limited. :/ Timing is especially bad when there is other data being transferred on Especially bad is still pretty vague. What might look bad on paper might be acceptable in context... It's not unusable, but IIRC it can get to several ms of jitter. the same USB bus, as is the case with combined audio/midi interfaces. Perhaps, but midi takes a lot less bandwidth than audio so how much worse could it get? It sounds like it wouldn't be a problem if you were overdubbing, but potentially in a live recording/performance if you are using the audio ins for a vocal mic or whatnot. I'm by no means an expert on this, but I think MIDI taking less bandwidth than audio is not really relevant; it's audio data being isochronous and True using a lot of bandwidth causing the MIDI timing to suffer. Right, but still, if one isn't planning on using the audio in concurrently it's not an intolerable situation. --ms
Re: [linux-audio-dev] a question re: the MIDI spec
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
Re: [linux-audio-dev] a question re: the MIDI spec
On Fri, 2004-09-10 at 23:00, John Check wrote: 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. M-Audio's USB MIDI keyboards are great, but I would not expect the audio variant to work as well. I also would not expect the audio hardware to be any better quality than what is in your average laptop. I haven't tried it though. Lee
Re: [linux-audio-dev] a question re: the MIDI spec
Jens M Andreasen wrote: [...] the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html - USB class compliantno drivers required for Windows XP or Mac OS X M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. Regards, Clemens
Re: [linux-audio-dev] a question re: the MIDI spec
On Thursday 09 September 2004, Clemens Ladisch wrote: M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. And now Avid (the company owning Digidesign) bought M-Audio. I hope to see the engineers that made the MBox hanging in the end of an USB cable. Regards, Pedro
Re: [linux-audio-dev] a question re: the MIDI spec
On Thu, Sep 09, 2004 at 07:18:57PM +0200, Pedro Lopez-Cabanillas wrote: On Thursday 09 September 2004, Clemens Ladisch wrote: M-Audio started following suit only after they hung their engineers with a USB cable and bought Evolution who had always made class-compliant devices. And now Avid (the company owning Digidesign) bought M-Audio. I hope to see the engineers that made the MBox hanging in the end of an USB cable. Really!?! when did that happen? Is that a good thing? Will we soon only have a single audio hardware manufacturer? -Eric rz.
Re: [linux-audio-dev] a question re: the MIDI spec
On ons, 2004-09-08 at 15:34, Dave Phillips wrote: Greetings: I'm doing some research for an article about Linux MIDI support. In my text I briefly describe the evolution of the MIDI specification since its adoption, mentioning things like MIDI Time Code, MMC, the sample dump standard, and the standard MIDI file. However, one item has me a bit mystified. I'm unable to ascertain whether multi-port interfaces are in fact described and supported by the spec. I checked the MMA docs on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers Handbook, but nowhere do those sources indicate explicit support for multi-port hardware. Are multi-port MIDI interfaces vendor-specific solutions or is there actually an extension to the MIDI spec somewhere that I'm just missing ? TIA! Muliport-interfaces were included in the initial discussions on the MIDI standard and referred to as star systems: tape-sync +-+ ---| SEQ |--- +-+ | V It was thought that a single interface would be good enough for stage and budget systems and that professional recording studios could overcome bandwith limitations by using one port for each synth-module attached. No specifics regarding naming nor discovery were mentioned. I suppose Roland, Sequential and Yamaha intended to build and sell those sequencers all by themselves ... The place to look for a universal standard for multiple midi-devices would be in the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html - USB class compliantno drivers required for Windows XP or Mac OS X mvh // Jens M Andreasen Best regards, dp
Re: [linux-audio-dev] a question re: the MIDI spec
On Wednesday 08 September 2004 09:34 am, Dave Phillips wrote: Greetings: I'm doing some research for an article about Linux MIDI support. In my text I briefly describe the evolution of the MIDI specification since its adoption, mentioning things like MIDI Time Code, MMC, the sample dump standard, and the standard MIDI file. However, one item has me a bit mystified. I'm unable to ascertain whether multi-port interfaces are in fact described and supported by the spec. I checked the MMA docs on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers Handbook, but nowhere do those sources indicate explicit support for multi-port hardware. Are multi-port MIDI interfaces vendor-specific solutions or is there actually an extension to the MIDI spec somewhere that I'm just missing ? TIA! It's implicit in the design. Ports are an object. Every MIDI entity has ports. Racking then up on any physical entity is like adding cylinders to an engine. Best regards, dp
Re: [linux-audio-dev] a question re: the MIDI spec
On Wednesday 08 September 2004 11:53 am, Jens M Andreasen wrote: On ons, 2004-09-08 at 15:34, Dave Phillips wrote: Greetings: I'm doing some research for an article about Linux MIDI support. In my text I briefly describe the evolution of the MIDI specification since its adoption, mentioning things like MIDI Time Code, MMC, the sample dump standard, and the standard MIDI file. However, one item has me a bit mystified. I'm unable to ascertain whether multi-port interfaces are in fact described and supported by the spec. I checked the MMA docs on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers Handbook, but nowhere do those sources indicate explicit support for multi-port hardware. Are multi-port MIDI interfaces vendor-specific solutions or is there actually an extension to the MIDI spec somewhere that I'm just missing ? TIA! Muliport-interfaces were included in the initial discussions on the MIDI standard and referred to as star systems: tape-sync +-+ ---| SEQ |--- +-+ V It was thought that a single interface would be good enough for stage and budget systems and that professional recording studios could overcome bandwith limitations by using one port for each synth-module attached. No specifics regarding naming nor discovery were mentioned. I suppose Roland, Sequential and Yamaha intended to build and sell those sequencers all by themselves ... The place to look for a universal standard for multiple midi-devices would be in the USB specification. And it even appears like some vendors are (finally!) starting to follow suit: http://midiman.com/products/en_us/KeystationPro88-main.html Yeow! I bought a keystation49e and all it took to get running was plug it in, turn it on. - USB class compliantno drivers required for Windows XP or Mac OS X mvh // Jens M Andreasen Best regards, dp
Re: [linux-audio-dev] a question re: the MIDI spec
On ons, 2004-09-08 at 17:40, Clemens Ladisch wrote: Dave Phillips wrote: I'm doing some research for an article about Linux MIDI support. In my text I briefly describe the evolution of the MIDI specification since its adoption, mentioning things like MIDI Time Code, MMC, the sample dump standard, and the standard MIDI file. However, one item has me a bit mystified. I'm unable to ascertain whether multi-port interfaces are in fact described and supported by the spec. SMF files can have the MIDI Port meta event (FF 21) to specify the port number for the following events. RP-019 describes the device name meta event (FF 09) with exactly the same purpose (http://www.midi.org/about-midi/smf/rp019.shtml), but it isn't used in practice. Dave! Clemens fine article pointer made me look around in midi.org and (just for the record) here is the spec for midi over firewire (with multiple midi-devices): http://www.midi.org/about-midi/rp27v10spec(1394).pdf Mmmm .. Seams like that old elephant in wheelchair got himself a brand new pair of rollerscaters ;) mvh // Jens M Andreasen HTH Clemens
