midi data rates

[Mark Harris]

hi,

Im trying to put a lot of data (250 x 4msg/sec) through the midi ports, and I appear (it may not be, but seems the most likely cause) to be getting some data loss.

basically Im getting 'stuck notes', which are by caused by channel pressure message coming in after a note off, or not being received. ... but I can see in a midi monitor they are being sent correctly.

what data rate can the STFM board handle, through the Midi DIN?  and at what rate is it being processed?  (Im wondering if a data buffer is being overrun somewhere)

are the midi messages sent out in strict order that they are received?

can I also confirm the mid handlers are single threaded.

also, I am seeing significant reduction in speed of processing as the number of midi messages increases, this is despite the CPU load on the board remaining very low (12-15% max)

I'll also try a different midi interface to see if it helps... as I'm not sure what my Pro14 AI can handle, (and it doesnt seem to be in any spec!)

(Unfortunately I cannot try the axoloti USB port, as I need to connect it to my mac to get the midi messages)

thanks

Mark 

[Johannes Taelman]

The midi input should handle saturated traffic.

1000 messages/second is near full saturation though, at 3 bytes/message the upper limit is 1041.6 messages/s, assuming no running status.

Could you verify

- your midi port is handling this fine by looping midi out to its midi in without Axoloti involved?

- create just a MIDI "soft thru" in Axoloti

pasting this in a patch should do that:

<patch>
   <obj type="midi/in/script" sha="82709d8f2cd722b129cb94767cdc4a23b41a5230" name="midi thru" x="84" y="140">
      <params/>
      <attribs>
         <text attributeName="script">
            <sText><![CDATA[MidiSend3(status, data1, data2);
]]></sText>
         </text>
      </attribs>
   </obj>
   <nets/>
   <notes><![CDATA[]]></notes>
</patch>

then connecting Axoloti midi out back to your pc midi interface and inspecting the output on a PC?

what data rate can the STFM board handle, through the Midi DIN?  and at what rate is it being processed?  (Im wondering if a data buffer is being overrun somewhere)

There is a 32 byte buffer. I think that is already oversized.

The DSP thread takes top priority, the Midi thread has normal priority.

The DSP thread activates at 3kHz. This is nearly as fast as a single MIDI byte can arrive.

 

are the midi messages sent out in strict order that they are received?

Yes.
 

can I also confirm the mid handlers are single threaded.

Midi input is a single thread calling the patch midi handler function after sorting out the status and data bytes.

This midi handler function can be interrupted by the DSP thread. And this is potentially unclean since the patch midi handler alters data used (but only read) in the DSP thread.

 

also, I am seeing significant reduction in speed of processing as the number of midi messages increases, this is despite the CPU load on the board remaining very low (12-15% max)

Speed of processing the midi messages?

Are you perhaps debugging the midi messages by printing to the console? That will certainly cause issues!

 

I'll also try a different midi interface to see if it helps... as I'm not sure what my Pro14 AI can handle, (and it doesnt seem to be in any spec!)

USB PC interfaces perform often less than perfect, I'm not surprised to measure several milliseonds of jitter. I haven't tested near-saturation behaviour of PC MIDI interfaces.

 

[Mark Harris]

Thanks Johannes

yeah, I definitely at the limit of saturation :) 

first, no, no debug logging and I don't think its processing overhead.

on Pro14, it appears the midi IN is not working, so Ive switch to a USB midi mate II (which works pretty well)

what Im seeing so far is:

if i reach saturation, and use your patch I start getting missing messages... usually appears to be note-offs (unfortunately), but this is probably just as I'm sending so many CC,

it also looks like message are incorrectly ordered/duplicated... but I need to do more thorough tests.

as a test, to check the USB midi without axoloti, I plugged it into my Virus TI in and thru, whilst it was turned off (so must be a hardware thru), I found at the same data rates, whilst the midi would lag behind, it seemed generally 'intact', except when extreme amounts of data pushed thru, but even then it was not too bad.

(my assumption is the USB midi mate II is probably not limited to the usual 32k baud limitation and perhaps even contains buffering logic.)

I'll experiment to see what rates I can achieve with axoloti.... my concern is each touch contains 1 PB, 1 channel pressure and 1 CC, and we want to have as high rate as possible, too keep sensitively high.  and I think we want to be allowing for 8 touches? but thats about 24 touch/sec .... or 41mS which is quite low.

generally I think your right about the 32 byte buffer... no point in a larger buffer, it just introduces more latency and if the processing doesnt keep up, it will fill up regardless of size.

is there anyway to increase the throughput? 

I thought I read somewhere, that whilst Midi DIN is rates at 32k, some microprocessors support 115k?

also I assume (?) that the USB via the host port will allow for higher data rates?  

(Ive no issue with saying midi din is restricted to 32k baud, if the USB ports can receive at much higher rates)

of course I recognise, higher data rates = more CPU = less DSP for processing sounds, but this is a trade off I think the musician can make a decision on?

BTW, on my patch I'm modulating the gain/vca at the midi rate, I assume this is at k-rate , which is 3kHZ.

[Johannes Taelman]

what Im seeing so far is:

if i reach saturation, and use your patch I start getting missing messages... usually appears to be note-offs (unfortunately), but this is probably just as I'm sending so many CC,

it also looks like message are incorrectly ordered/duplicated... but I need to do more thorough tests.

I'd be surprised, but never exclude a bug on my side completely.

 

as a test, to check the USB midi without axoloti, I plugged it into my Virus TI in and thru, whilst it was turned off (so must be a hardware thru),

Midi Thru should be after the optocoupler, I'm surprised the Virus has a working midi thru without power.

 

I found at the same data rates, whilst the midi would lag behind, it seemed generally 'intact', except when extreme amounts of data pushed thru, but even then it was not too bad.

(my assumption is the USB midi mate II is probably not limited to the usual 32k baud limitation and perhaps even contains buffering logic.)

I'll experiment to see what rates I can achieve with axoloti.... my concern is each touch contains 1 PB, 1 channel pressure and 1 CC, and we want to have as high rate as possible, too keep sensitively high.  and I think we want to be allowing for 8 touches? but thats about 24 touch/sec .... or 41mS which is quite low.

8 keys with 3 messages per key need 23ms transmission time, you'd get 43.4 Hz update rate maximum. Yeah that's not going to be snappy. A polyphonic bend/pressure Midi keyboard should thin out data and prioritize the most significant changes rather than cycling through all active keys and messages, to get the maximum out of the 1983 standard.

I'd suggest not to go over 90% of the maximum MIDI bandwidth, lot's of equipment will show issues.

 

generally I think your right about the 32 byte buffer... no point in a larger buffer, it just introduces more latency and if the processing doesnt keep up, it will fill up regardless of size.

is there anyway to increase the throughput? 

I thought I read somewhere, that whilst Midi DIN is rates at 32k, some microprocessors support 115k?

The STM32F4 can even handle up to 5.25mbit. But Midi DIN is always 31250 bps. Maybe some Midi equipment supports higher rates, but this is rare and off-standard.

 

also I assume (?) that the USB via the host port will allow for higher data rates?  

(Ive no issue with saying midi din is restricted to 32k baud, if the USB ports can receive at much higher rates)

Yes, USB over Midi can do faster. But this is problematic when this traffic ever needs to get forwarded to DIN Midi. Thinning out a Midi stream is ill-defined. I think transmitting Midi faster over USB than DIN can deal with will cause buffer overflows in a lot of equipment on the market. When testing a Roli Seaboard, this was with a PC forwarding USB-Midi to DIN-Midi. The USB host on Axoloti was not developed yet at that time. The Seaboard didn't oversaturate the DIN-Midi.

 

of course I recognise, higher data rates = more CPU = less DSP for processing sounds, but this is a trade off I think the musician can make a decision on?

The DSP thread takes the highest priority, less DSP load means more time available for handling MIDI.

 

BTW, on my patch I'm modulating the gain/vca at the midi rate, I assume this is at k-rate , which is 3kHZ.

Midi rate and k-rate are asynchronous. K-rate is currently always 3 kHz : 48kHz audio sample rate, processed in blocks of 16 samples.
The processing of Midi input is event-driven.

[Mark Harris]

As i said, no problem with Midi DIN limits... as you say its a known, and with USB allowing more thats fine (accepting additional load required)

and yes, both soundplane and eigenharp can also limit the data traffic when using slower connections, just there is a lower limit to where you want to be.

(continuum is also outputting over Midi DIN, so it cannot saturate)  ... the MPE spec will also help, as it also reduces the data sent a little bit.

Virus TI, sorry was in standby...  I kind if meant it wasn't doing a software thru (which its also capable of doing)

anyway, good news is, Ive noticed the script you gave me was corrupting the stream, as it was sending channel pressure as 3 bytes,

so I adapated to:

<patch>

   <obj type="midi/in/script" sha="82709d8f2cd722b129cb94767cdc4a23b41a5230" name="midi thru" x="84" y="140">

      <params/>

      <attribs>

         <text attributeName="script">

            <sText><![CDATA[if( (status& 0xF0) == MIDI_CHANNEL_PRESSURE )

{

MidiSend1(status);

MidiSend1(data1);

}

else

MidiSend3(status, data1, data2);

]]></sText>

         </text>

      </attribs>

   </obj>

   <nets/>

   <notes><![CDATA[]]></notes>

</patch>

with this I seem to be getting the same behaviour with Axoloti in the loop, or straight through, and this appears to limited at the rate we expect i.e. ~31kbps

btw, perhaps we should add a MidiSend2, to firmware.c/h ?  (handy for 2 byte messages)

anyway, I'll decimate my data to ~90% max, and then do further testing once the host USB port can accept data (i.e. the microUSB, as i don't think the Mac can act as a midi device, only host)

thanks for the info, very informative 

Mark

[Johannes Taelman]

On Mon, Apr 20, 2015 at 3:19 PM, Mark Harris <ma...@technobear.com> wrote:

anyway, good news is, Ive noticed the script you gave me was corrupting the stream, as it was sending channel pressure as 3 bytes,

sorry, forgot about 2 byte messages in that script, yes...
 

btw, perhaps we should add a MidiSend2, to firmware.c/h ?  (handy for 2 byte messages)

yes.

 

anyway, I'll decimate my data to ~90% max, and then do further testing once the host USB port can accept data (i.e. the microUSB, as i don't think the Mac can act as a midi device, only host)

Correct. A USB Midi device personality on Axoloti will come one day. And its usb-serial personality will be replaced with generic bulk transport.

In the meantime, you can inject Midi commands over Axoloti's usb-serial.
DatanoiseTV made a rtp-midi proxy for it, but I don't know what language this is:
https://gist.github.com/DatanoiseTV/6a59fc66517fbd923ed9

You can connect to usb-serial with only one program, so you can't have the patcher connected at the same time.