usbMIDI transmission error
- Thread starter Rolfdegen
- Start date
PaulStoffregen
Well-known member
I've made another update to the USB MIDI documentation page to add a "Receiving Large System Exclusive Messages" section.
I tried to get my original (large) synth project to compile with the newly installed Arduino 2.1 IDE for several hours without success, and in the end just went back to 1.8.19 where it worked straight away without issues. Presumably with the new IDE install it wasn't correctly accessing one of the many libraries I use in the project.
But I do have the combination of IDE 1.8.19 and teensyduino 1.58 now giving me reliable sysex transfers without the need for the additional flush. One belated thought I had as to why I didn't before installing 1.58 was that I remembered I had also altered usb.c so it forced the USB to operate at 12Mhz to allow slower usb isolators to work. If I get the chance, I'll see if altering usb.c in teensyduino 1.58 in that way again degrades the sysex transfer reliability.
But I do have the combination of IDE 1.8.19 and teensyduino 1.58 now giving me reliable sysex transfers without the need for the additional flush. One belated thought I had as to why I didn't before installing 1.58 was that I remembered I had also altered usb.c so it forced the USB to operate at 12Mhz to allow slower usb isolators to work. If I get the chance, I'll see if altering usb.c in teensyduino 1.58 in that way again degrades the sysex transfer reliability.
Last edited:
I ran the test code from message #100 with a Teensy 3.6, using the same fresh install of teensyduino 1.58 just now. Unfortunately it is not as reliable as with the T4, and using the usb_midi.c variant I described in message #51 eliminated the errors. So it seems worth retaining those changes for sysex transfers using T3.6 for now. If it is of interest to you, and you have a T3.6, please try this for yourself and report your findings. Thanks.
Rolfdegen
Well-known member
I wait 20ms after each sent patch block !
If I don't do any wait cycles after a block I have errors.
Youtube: https://youtu.be/ghTelpHu6J4
If I don't do any wait cycles after a block I have errors.
Youtube: https://youtu.be/ghTelpHu6J4
Last edited:
Rolfdegen
Well-known member
PaulS
Well-known member
Well, changing the lines delayMicroseconds_WhileDiscardingInput(50000); to delayMicroseconds_WhileDiscardingInput(20000); to effectively wait 20ms after each message, did not improve the failure rate: 22 fails [truncated 3 bytes short] out of 6000 messages.
Paul
Been playing with the sketch in MSG# 100 on a T3.6. Using a two year old Lenovo laptop, Win10 upgraded to 11, fresh IDE1.8.19 TD 1.58. No edits have been done on any library. Monitoring with Bomes.
After many button presses eventually do see Sysex messages with three bytes missing.
Uncommented usb_midi_flush_output(), same result as above.
Repeated with delayMicroseconds_WhileDiscardingInput(20000). Eventually Sysex messages pop up with three bytes missing.
Have had the T3.6 hang so Bomes displays no further input. Exit and Restart Bomes still no input, need to reboot T3.6.
After many button presses eventually do see Sysex messages with three bytes missing.
Uncommented usb_midi_flush_output(), same result as above.
Repeated with delayMicroseconds_WhileDiscardingInput(20000). Eventually Sysex messages pop up with three bytes missing.
Have had the T3.6 hang so Bomes displays no further input. Exit and Restart Bomes still no input, need to reboot T3.6.
Gets more interesting. Switched focus to my own project, an editor/control surface for the Roland JV XP series. Communicates with the rest of the kit via Serial MIDI. Has edit buffers for 16 patches. A patch consists of one 85 byte and four 140 byte Sysex Messages. Using a 50ms gap between messages to stop the synth complaining about buffer overrun - targeting User area so is writing to 1990's Flash.
Edited code to output to usbMIDI and tested. A buttonpress transmits a block of 16 patches, a total of 10000 bytes.
Took less than a dozen presses to produce this.
Inserted delayMicroseconds_WhileDiscardingInput(5000); appropriately and retested.
Took well over a hundred presses to produce this:-
Interesting is the bytes go missing in exactly the same place in the message in both test cases.
Time to cook dinner so will be thinking about some adjustments to get it running on a bare T4.1.
Edited code to output to usbMIDI and tested. A buttonpress transmits a block of 16 patches, a total of 10000 bytes.
Took less than a dozen presses to produce this.
Inserted delayMicroseconds_WhileDiscardingInput(5000); appropriately and retested.
Took well over a hundred presses to produce this:-
Interesting is the bytes go missing in exactly the same place in the message in both test cases.
Time to cook dinner so will be thinking about some adjustments to get it running on a bare T4.1.
Rolfdegen
Well-known member
I haven't found any other solution!
Transmission errors occur again and again.
I set the waiting time between two SysEx transmissions to very large 500ms without success.
If I comment out usb_midi_flush_output() in USB.c file it works very fine. I've tested it 30x and more.. no transmission errors
USB.c
Transmission errors occur again and again.
I set the waiting time between two SysEx transmissions to very large 500ms without success.
If I comment out usb_midi_flush_output() in USB.c file it works very fine. I've tested it 30x and more.. no transmission errors
USB.c
My screenshots above show that three consecutive bytes go missing from around byte 124 of a 140 byte message. Thinking of adjusting @rvh's test in MSG# 100. First to replace the Zeros with consecutive numbers 0 - 127, makes it easier to spot when things go awry. Second to test with progressively shorter messages and look for message length where error does not happen.
Then there's the Windows spectre. Ok, let's rule it out with a Teensy Host running a simple sketch reading the incoming Sysex message and report if received message length < transmitted message length and print the message to Serial monitor as a starting point.
Need to catch up with a backlog of repairs and shopping..
Then there's the Windows spectre. Ok, let's rule it out with a Teensy Host running a simple sketch reading the incoming Sysex message and report if received message length < transmitted message length and print the message to Serial monitor as a starting point.
Need to catch up with a backlog of repairs and shopping..
PaulStoffregen
Well-known member
After long tests, I have now also found errors when sending SysEx data from Teensy 4.1 to the PC
If you want me to look at this again, you need to post a complete program and detailed instructions to reproduce the problem. Even if the program is a trivial change to anything previously posted on this thread, please understand I only put this thread back on my list of issues to investigate when a complete program and clear instructions are posted. Today this issue is not on my list, so I am not currently planning to do any more work on this issue. Even if 1000 more messages are written describing the problem, the only factor which will get me to actually investigate (again) is just 1 message with complete code and details to reproduce the problem.
Also please understand I have a very long list of other matters demanding my attention. Even if you post a program today, I will not look into this issue again until at least July or later. When I do, if I can't reproduce the problem quickly, I may not spend 3 days trying dozens of changes and repeatedly asking as I did earlier this week. Please take your time to compose a program and verify it really does reproduce the problem.
PaulStoffregen
Well-known member
I usually test with the most recent beta version, though I may also test with the last stable release if I can't reproduce it with the beta.
Hopefully this should be obvious, but as a gentle reminder, if you're using an older version or if your core library has modifications, check your program against the latest beta and last stable release before asking me to investigate. Reporting an issue which has already been addressed by recent releases only ends up wasting everyone's time.
Hopefully this should be obvious, but as a gentle reminder, if you're using an older version or if your core library has modifications, check your program against the latest beta and last stable release before asking me to investigate. Reporting an issue which has already been addressed by recent releases only ends up wasting everyone's time.
BriComp
Well-known member
Where is the sketch that produced NO errors?
Sketches that don't produce errors are just as important to see as those that do.
The solution for T3.x is not the same as T4.x. Have a look at my message #51 where I show the changes needed to usb_midi.c for T3 (not usb.c). No additional flush is needed in the user code. I tested the most recent teensyduino, and it still needs this change on my system to eliminate the errors.
Rolfdegen
Well-known member
This is a test program for Teensy 4.1 to send 128 SysEx data blocks via usbMidi or Midi 5pol to the pc.
Number of blocks and waiting time between send a block can be changed.
All attempts with active usb_midi_flush_output() in USB.c file cause receive errors.
My synthesizers (DeepMind 6, Waldorf Blofeld) have usbMIDI transfer rate about 2.0-3.0 KB/s
change USB.c (Teensy 4.1)
If flush_usb is commented out, there are no transmission errors. Even with very small waiting times (2ms very fast about 195 KB/s, 130 normal about 3.0 KB/s) between the SysEx blocks.
Greetings from germany. Rolf
Number of blocks and waiting time between send a block can be changed.
All attempts with active usb_midi_flush_output() in USB.c file cause receive errors.
My synthesizers (DeepMind 6, Waldorf Blofeld) have usbMIDI transfer rate about 2.0-3.0 KB/s
Code:
//*****************************************************************
// Send SysEx data to usbMidi or MIDI 5pol (c) 6.2023
//*****************************************************************
#include <MIDI.h>
#include <usb_midi.h>
#include <Bounce2.h>
#define chunkSize 401
#define Blocknumbers 128
#define delayAmt 130 // about 3.0KB/s
#define buttonPin PIN_A3
const int ledPin = 13;
Bounce myButton = Bounce();
boolean startFlag = false;
byte data[chunkSize];
MIDI_CREATE_INSTANCE(HardwareSerial, Serial1, MIDI); // MIDI 5pol
//***************************************************************
// init setup
//***************************************************************
void setup() {
MIDI.begin(); // MIDI 5pol
usbMIDI.begin(); // usbMIDI
pinMode(ledPin, OUTPUT);
pinMode(buttonPin, INPUT_PULLUP);
myButton.attach(buttonPin);
myButton.interval(5); // 5ms zum Entprellen
fillBuff();
}
//****************************************************************
// fill buffer
//****************************************************************
void fillBuff() {
unsigned scratch;
// set Start and End Byte for SysEx
data[0] = 0xF0;
data[chunkSize - 1] = 0xF7;
// fill with data
for (uint16_t ct = 1; ct < (chunkSize-1); ct++) {
scratch = (ct & 0b01111111);
data[ct] = scratch;
}
}
//***************************************************************
// transmit SysEx data
//***************************************************************
void sendSysExData () {
usbMIDI.sendSysEx(chunkSize, data, true); // usbMidi
//MIDI.sendSysEx(chunkSize, data, true); // Midi 5pol Teensy 4.1 Pin 1 (TX1)
digitalWrite(ledPin, HIGH);
}
//**************************************************************
// loop
//**************************************************************
void loop() {
// press Key for transmit SysEx data
myButton.update();
if (myButton.fallingEdge()) {
startFlag = true;
}
// send SysEx Blocks
if (startFlag == true){
for (uint8_t i = 0; i < Blocknumbers; i++) {
sendSysExData();
delay(delayAmt);
}
startFlag = false;
digitalWrite(ledPin, LOW);
}
}change USB.c (Teensy 4.1)
If flush_usb is commented out, there are no transmission errors. Even with very small waiting times (2ms very fast about 195 KB/s, 130 normal about 3.0 KB/s) between the SysEx blocks.
Greetings from germany. Rolf
Last edited:
Rolfdegen
Well-known member
Hi Rolf, I just ran your test code 20x and saw no errors in SXsend using teensyduino 1.58 with an unmodified T4 usb.c core file (i.e. flush enabled). For me this problem went away on T4.x (but not T3.x) when I updated to the latest teensyduino (running windows 10 pro). I did first also update to arduino 2.1, but then uninstalled it and reinstalled 1.8.19 again. I wonder if this variation could be a windows USB driver issue?
